From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7828.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc7828.txt (limited to 'doc/rfc/rfc7828.txt') diff --git a/doc/rfc/rfc7828.txt b/doc/rfc/rfc7828.txt new file mode 100644 index 0000000..e4d6d80 --- /dev/null +++ b/doc/rfc/rfc7828.txt @@ -0,0 +1,619 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Wouters +Request for Comments: 7828 Red Hat +Category: Standards Track J. Abley +ISSN: 2070-1721 Dyn, Inc. + S. Dickinson + Sinodun + R. Bellis + ISC + April 2016 + + + The edns-tcp-keepalive EDNS0 Option + +Abstract + + DNS messages between clients and servers may be received over either + UDP or TCP. UDP transport involves keeping less state on a busy + server, but can cause truncation and retries over TCP. Additionally, + UDP can be exploited for reflection attacks. Using TCP would reduce + retransmits and amplification. However, clients commonly use TCP + only for retries and servers typically use idle timeouts on the order + of seconds. + + This document defines an EDNS0 option ("edns-tcp-keepalive") that + allows DNS servers to signal a variable idle timeout. This + signalling encourages the use of long-lived TCP connections by + allowing the state associated with TCP transport to be managed + effectively with minimal impact on the DNS transaction time. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7828. + + + + + + + + + +Wouters, et al. Standards Track [Page 1] + +RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016 + + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 + 3. The edns-tcp-keepalive Option . . . . . . . . . . . . . . . . 5 + 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5 + 3.2. Use by DNS Clients . . . . . . . . . . . . . . . . . . . 5 + 3.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 5 + 3.2.2. Receiving Responses . . . . . . . . . . . . . . . . . 6 + 3.3. Use by DNS Servers . . . . . . . . . . . . . . . . . . . 6 + 3.3.1. Receiving Queries . . . . . . . . . . . . . . . . . . 6 + 3.3.2. Sending Responses . . . . . . . . . . . . . . . . . . 6 + 3.4. TCP Session Management . . . . . . . . . . . . . . . . . 7 + 3.5. Non-clean Paths . . . . . . . . . . . . . . . . . . . . . 8 + 3.6. Anycast Considerations . . . . . . . . . . . . . . . . . 8 + 4. Intermediary Considerations . . . . . . . . . . . . . . . . . 8 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 + 7.2. Informative References . . . . . . . . . . . . . . . . . 10 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 + + + + + + + + + + + + + +Wouters, et al. Standards Track [Page 2] + +RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016 + + +1. Introduction + + DNS messages between clients and servers may be received over either + UDP or TCP [RFC1035]. Historically, DNS clients used APIs that only + facilitated sending and receiving a single query over either UDP or + TCP. New APIs and deployment of DNSSEC validating resolvers on hosts + that in the past were using stub resolving only is increasing the DNS + client base that prefer using long-lived TCP connections. Long-lived + TCP connections can result in lower request latency than the case + where UDP transport is used and truncated responses are received. + This is because clients that retry over TCP following a truncated UDP + response typically only use the TCP session for a single (request, + response) pair, continuing with UDP transport for subsequent queries. + + The use of TCP transport requires state to be retained on DNS + servers. If a server is to perform adequately with a significant + query load received over TCP, it must manage its available resources + to ensure that all established TCP sessions are well-used, and idle + connections are closed after an appropriate amount of time. + + UDP transport is stateless, and hence presents a much lower resource + burden on a busy DNS server than TCP. An exchange of DNS messages + over UDP can also be completed in a single round trip between + communicating hosts, resulting in optimally short transaction times. + UDP transport is not without its risks, however. + + A single-datagram exchange over UDP between two hosts can be + exploited to enable a reflection attack on a third party. Response + Rate Limiting [RRL] is designed to help mitigate such attacks against + authoritative-only servers. One feature of RRL is to let some amount + of responses "slip" through the rate limiter. These are returned + with the TC (truncation) bit set, which causes legitimate clients to + resend the same query using TCP transport. + + [RFC1035] specified a maximum DNS message size over UDP transport of + 512 bytes. Deployment of DNSSEC [RFC4033] and other protocols + subsequently increased the observed frequency at which responses + exceed this limit. EDNS0 [RFC6891] allows DNS messages larger than + 512 bytes to be exchanged over UDP, with a corresponding increased + incidence of fragmentation. Fragmentation is known to be problematic + in general, and has also been implicated in increasing the risk of + cache poisoning attacks [fragmentation-considered-poisonous]. + + TCP transport is less susceptible to the risks of fragmentation and + reflection attacks. However, TCP transport for DNS as currently + deployed has expensive setup overhead, compared to using UDP (when no + retry is required). + + + + +Wouters, et al. Standards Track [Page 3] + +RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016 + + + The overhead of the three-way TCP handshake for a single DNS + transaction is substantial, increasing the transaction time for a + single (request, response) pair of DNS messages from 1x RTT to 2x + RTT. There is no such overhead for a session that is already + established; therefore, the overhead of the initial TCP handshake is + minimised when the resulting session is used to exchange multiple DNS + message pairs over a single session. The extra RTT time for session + setup can be represented as the equation (1 + N)/N, where N + represents the number of DNS message pairs that utilize the session + and the result approaches unity as N increases. + + With increased deployment of DNSSEC and new RR types containing + application-specific cryptographic material, there is an increase in + the prevalence of truncated responses received over UDP with retries + over TCP. The overhead for a DNS transaction over UDP truncated due + to RRL is 3x RTT higher than the overhead imposed on the same + transaction initiated over TCP. + + This document proposes a signalling mechanism between DNS clients and + servers that encourages the use of long-lived TCP connections by + allowing the state associated with TCP transport to be managed + effectively with minimal impact on the DNS transaction time. + + This mechanism will be of benefit for both stub-resolver and + resolver-authoritative TCP connections. In the latter case, the + persistent nature of the TCP connection can provide improved defence + against attacks including DDoS. + + The reduced overhead of this extension adds up significantly when + combined with other EDNS0 extensions, such as [CHAIN-QUERY] and + [DNS-over-TLS]. For example, the combination of these EDNS0 + extensions make it possible for hosts on high-latency mobile networks + to natively and efficiently perform DNSSEC validation and encrypt + queries. + +2. Requirements Notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + + + + + + + + +Wouters, et al. Standards Track [Page 4] + +RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016 + + +3. The edns-tcp-keepalive Option + + This document specifies a new EDNS0 [RFC6891] option, edns-tcp- + keepalive, which can be used by DNS clients and servers to signal a + willingness to keep an idle TCP session open to conduct future DNS + transactions, with the idle timeout being specified by the server. + This specification does not distinguish between different types of + DNS client and server in the use of this option. + + [RFC7766] defines an 'idle DNS-over-TCP session' from both the client + and server perspective. The idle timeout described here begins when + the idle condition is met per that definition and should be reset + when that condition is lifted, i.e., when a client sends a message or + when a server receives a message on an idle connection. + +3.1. Option Format + + The edns-tcp-keepalive option is encoded as follows: + + 1 2 3 + 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 + +-------------------------------+-------------------------------+ + ! OPTION-CODE ! OPTION-LENGTH ! + +-------------------------------+-------------------------------+ + | TIMEOUT ! + +-------------------------------+ + + where: + + OPTION-CODE: the EDNS0 option code assigned to edns-tcp-keepalive, + 11 + + OPTION-LENGTH: the value 0 if the TIMEOUT is omitted, the value 2 + if it is present; + + TIMEOUT: an idle timeout value for the TCP connection, specified in + units of 100 milliseconds, encoded in network byte order. + +3.2. Use by DNS Clients + +3.2.1. Sending Queries + + DNS clients MUST NOT include the edns-tcp-keepalive option in queries + sent using UDP transport. + + DNS clients MAY include the edns-tcp-keepalive option in the first + query sent to a server using TCP transport to signal their desire to + keep the connection open when idle. + + + +Wouters, et al. Standards Track [Page 5] + +RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016 + + + DNS clients MAY include the edns-tcp-keepalive option in subsequent + queries sent to a server using TCP transport to signal their + continued desire to keep the connection open when idle. + + Clients MUST specify an OPTION-LENGTH of 0 and omit the TIMEOUT + value. + +3.2.2. Receiving Responses + + A DNS client that receives a response using UDP transport that + includes the edns-tcp-keepalive option MUST ignore the option. + + A DNS client that receives a response using TCP transport that + includes the edns-tcp-keepalive option MAY keep the existing TCP + session open when it is idle. It SHOULD honour the timeout received + in that response (overriding any previous timeout) and initiate close + of the connection before the timeout expires. + + A DNS client that receives a response that includes the edns-tcp- + keepalive option with a TIMEOUT value of 0 SHOULD send no more + queries on that connection and initiate closing the connection as + soon as it has received all outstanding responses. + + A DNS client that sent a query containing the edns-keepalive-option + but receives a response that does not contain the edns-keepalive- + option SHOULD assume the server does not support keepalive and behave + following the guidance in [RFC7766]. This holds true even if a + previous edns-keepalive-option exchange occurred on the existing TCP + connection. + +3.3. Use by DNS Servers + +3.3.1. Receiving Queries + + A DNS server that receives a query using UDP transport that includes + the edns-tcp-keepalive option MUST ignore the option. + + A DNS server that receives a query using TCP transport that includes + the edns-tcp-keepalive option MAY modify the local idle timeout + associated with that TCP session if resources permit. + +3.3.2. Sending Responses + + A DNS server that receives a query sent using TCP transport that + includes an OPT RR (with or without the edns-tcp-keepalive option) + MAY include the edns-tcp-keepalive option in the response to signal + the expected idle timeout on a connection. Servers MUST specify the + TIMEOUT value that is currently associated with the TCP session. It + + + +Wouters, et al. Standards Track [Page 6] + +RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016 + + + is reasonable for this value to change according to local resource + constraints. The DNS server SHOULD send an edns-tcp-keepalive option + with a timeout of 0 if it deems its local resources are too low to + service more TCP keepalive sessions or if it wants clients to close + currently open connections. + +3.4. TCP Session Management + + Both DNS clients and servers are subject to resource constraints that + will limit the extent to which TCP sessions can persist. Effective + limits for the number of active sessions that can be maintained on + individual clients and servers should be established, either as + configuration options or by interrogation of process limits imposed + by the operating system. Servers that implement edns-tcp-keepalive + should also engage in TCP connection management by recycling existing + connections when appropriate, closing connections gracefully, and + managing request queues to enable fair use. + + In the event that there is greater demand for TCP sessions than can + be accommodated, servers may reduce the TIMEOUT value signalled in + successive DNS messages to minimise idle time on existing sessions. + This also allows, for example, clients with other candidate servers + to query to establish new TCP sessions with different servers in + expectation that an existing session is likely to be closed or to + fall back to UDP. + + Based on TCP session resources, servers may signal a TIMEOUT value of + 0 to request clients to close connections as soon as possible. This + is useful when server resources become very low or a denial-of- + service attack is detected and further maximises the shifting of + TIME_WAIT state to well-behaved clients. + + However, it should be noted that RFC 6891 states: + + Lack of presence of an OPT record in a request MUST be taken as an + indication that the requestor does not implement any part of this + specification and that the responder MUST NOT include an OPT + record in its response. + + Since servers must be faithful to this specification even on a + persistent TCP connection, it means that (following the initial + exchange of timeouts) a server may not be presented with the + opportunity to signal a change in the idle timeout associated with a + connection if the client does not send any further requests + containing EDNS0 OPT RRs. This limitation makes persistent + connection handling via an initial idle timeout signal more + + + + + +Wouters, et al. Standards Track [Page 7] + +RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016 + + + attractive than a mechanism that establishes default persistence and + then uses a connection close signal (in a similar manner to HTTP 1.1 + [RFC7230]). + + If a client includes the edns-tcp-keepalive option in the first + query, it SHOULD include an EDNS0 OPT RR periodically in any further + messages it sends during the TCP session. This will increase the + chance of the client being notified should the server modify the + timeout associated with a session. The algorithm for choosing when + to do this is out of scope of this document and is left up to the + implementor and/or operator. + + DNS clients and servers MAY close a TCP session at any time in order + to manage local resource constraints. The algorithm by which clients + and servers rank active TCP sessions in order to determine which to + close is not specified in this document. + +3.5. Non-clean Paths + + Many paths between DNS clients and servers suffer from poor hygiene, + limiting the free flow of DNS messages that include particular EDNS0 + options or messages that exceed a particular size. A fallback + strategy similar to that described in [RFC6891], Section 6.2.2 SHOULD + be employed to avoid persistent interference due to non-clean paths. + +3.6. Anycast Considerations + + DNS servers of various types are commonly deployed using anycast + [RFC4786]. + + Changes in network topology between clients and anycast servers may + cause disruption to TCP sessions making use of edns-tcp-keepalive + more often than with TCP sessions that omit it, since the TCP + sessions are expected to be longer lived. It might be possible for + anycast servers to avoid disruption due to topology changes by making + use of TCP multipath [RFC6824] to anchor the server side of the TCP + connection to an unambiguously unicast address. + +4. Intermediary Considerations + + It is RECOMMENDED that DNS intermediaries that terminate TCP + connections implement edns-tcp-keepalive. An intermediary that does + not implement edns-tcp-keepalive but sits between a client and server + that both support edns-tcp-keepalive might close idle connections + unnecessarily. + + + + + + +Wouters, et al. Standards Track [Page 8] + +RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016 + + +5. Security Considerations + + The edns-tcp-keepalive option can potentially be abused to request + large numbers of long-lived sessions in a quick burst. When a DNS + server detects abusive behaviour, it SHOULD immediately close the TCP + connection and free the resources used. + + Servers could choose to monitor client behaviour with respect to the + edns-tcp-keepalive option to build up profiles of clients that do not + honour the specified timeout. + + Readers are advised to familiarise themselves with the security + considerations outlined in [RFC7766] + +6. IANA Considerations + + IANA has assigned an EDNS0 option code for the edns-tcp-keepalive + option from the "DNS EDNS0 Option Codes (OPT)" registry as follows: + + +-------+--------------------+----------+-----------+ + | Value | Name | Status | Reference | + +-------+--------------------+----------+-----------+ + | 11 | edns-tcp-keepalive | Standard | RFC 7828 | + +-------+--------------------+----------+-----------+ + +7. References + +7.1. Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, DOI 10.17487/RFC4033, March 2005, + . + + [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast + Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, + December 2006, . + + + + + +Wouters, et al. Standards Track [Page 9] + +RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016 + + + [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms + for DNS (EDNS(0))", STD 75, RFC 6891, + DOI 10.17487/RFC6891, April 2013, + . + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, + . + + [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and + D. Wessels, "DNS Transport over TCP - Implementation + Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, + . + +7.2. Informative References + + [CHAIN-QUERY] + Wouters, P., "Chain Query requests in DNS", Work in + Progress, draft-ietf-dnsop-edns-chain-query-07, February + 2016. + + [DNS-over-TLS] + Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., + and P. Hoffman, "Specification for DNS over TLS", Work in + Progress, draft-ietf-dprive-dns-over-tls-09, March 2016. + + [fragmentation-considered-poisonous] + Herzberg, A. and H. Shulman, "Fragmentation Considered + Poisonous", arXiv: 1205.4011, May 2012, + . + + [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, + "TCP Extensions for Multipath Operation with Multiple + Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, + . + + [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting + (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012, + . + + + + + + + + + + + +Wouters, et al. Standards Track [Page 10] + +RFC 7828 The edns-tcp-keepalive EDNS0 Option April 2016 + + +Acknowledgements + + The authors acknowledge the contributions of Jinmei TATUYA and Mark + Andrews. Thanks to Duane Wessels for detailed review and the many + others who contributed to the mailing list discussion. + +Authors' Addresses + + Paul Wouters + Red Hat + + Email: pwouters@redhat.com + + + Joe Abley + Dyn, Inc. + 103-186 Albert Street + London, ON N6A 1M1 + Canada + + Phone: +1 519 670 9327 + Email: jabley@dyn.com + + + Sara Dickinson + Sinodun Internet Technologies + Magdalen Centre + Oxford Science Park + Oxford OX4 4GA + United Kingdom + + Email: sara@sinodun.com + URI: http://sinodun.com + + + Ray Bellis + Internet Systems Consortium, Inc + 950 Charter Street + Redwood City, CA 94063 + United States + + Phone: +1 650 423 1200 + Email: ray@isc.org + URI: http://www.isc.org + + + + + + + +Wouters, et al. Standards Track [Page 11] + -- cgit v1.2.3