The edns-tcp-keepalive EDNS0 Option
RFC 7828
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
Show full document text