doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

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, <http://www.rfc-editor.org/info/rfc1035>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc4033>.
+
+   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
+              Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
+              December 2006, <http://www.rfc-editor.org/info/rfc4786>.
+
+
+
+
+
+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,
+              <http://www.rfc-editor.org/info/rfc6891>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc7230>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc7766>.
+
+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,
+              <http://arxiv.org/abs/1205.4011>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc6824>.
+
+   [RRL]      Vixie, P. and V. Schryver, "DNS Response Rate Limiting
+              (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012,
+              <https://ftp.isc.org/isc/pubs/tn/isc-tn-2012-1.txt>.
+
+
+
+
+
+
+
+
+
+
+
+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]
+