draft-ietf-dnsop-5966bis-03.txt   draft-ietf-dnsop-5966bis-04.txt 
dnsop J. Dickinson dnsop J. Dickinson
Internet-Draft S. Dickinson Internet-Draft S. Dickinson
Obsoletes: 5966 (if approved) Sinodun Obsoletes: 5966 (if approved) Sinodun
Intended status: Standards Track R. Bellis Intended status: Standards Track R. Bellis
Expires: March 23, 2016 ISC Expires: May 6, 2016 ISC
A. Mankin A. Mankin
D. Wessels D. Wessels
Verisign Labs Verisign Labs
September 20, 2015 November 3, 2015
DNS Transport over TCP - Implementation Requirements DNS Transport over TCP - Implementation Requirements
draft-ietf-dnsop-5966bis-03 draft-ietf-dnsop-5966bis-04
Abstract Abstract
This document specifies the requirement for support of TCP as a This document specifies the requirement for support of TCP as a
transport protocol for DNS implementations and provides guidelines transport protocol for DNS implementations and provides guidelines
towards DNS-over-TCP performance on par with that of DNS-over-UDP. towards DNS-over-TCP performance on par with that of DNS-over-UDP.
This document obsoletes RFC5966.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 23, 2016. This Internet-Draft will expire on May 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Transport Protocol Selection . . . . . . . . . . . . . . . . 5 5. Transport Protocol Selection . . . . . . . . . . . . . . . . 5
6. Connection Handling . . . . . . . . . . . . . . . . . . . . . 6 6. Connection Handling . . . . . . . . . . . . . . . . . . . . . 6
6.1. Current practices . . . . . . . . . . . . . . . . . . . . 6 6.1. Current practices . . . . . . . . . . . . . . . . . . . . 6
6.1.1. Clients . . . . . . . . . . . . . . . . . . . . . . . 7 6.1.1. Clients . . . . . . . . . . . . . . . . . . . . . . . 6
6.1.2. Servers . . . . . . . . . . . . . . . . . . . . . . . 7 6.1.2. Servers . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 7 6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 7
6.2.1. Connection Re-use . . . . . . . . . . . . . . . . . . 7 6.2.1. Connection Re-use . . . . . . . . . . . . . . . . . . 7
6.2.1.1. Query Pipelining . . . . . . . . . . . . . . . . 8 6.2.1.1. Query Pipelining . . . . . . . . . . . . . . . . 8
6.2.2. Concurrent connections . . . . . . . . . . . . . . . 8 6.2.2. Concurrent connections . . . . . . . . . . . . . . . 8
6.2.3. Idle Timeouts . . . . . . . . . . . . . . . . . . . . 9 6.2.3. Idle Timeouts . . . . . . . . . . . . . . . . . . . . 9
6.2.4. Tear Down . . . . . . . . . . . . . . . . . . . . . . 9 6.2.4. Tear Down . . . . . . . . . . . . . . . . . . . . . . 9
7. Response Reordering . . . . . . . . . . . . . . . . . . . . . 9 7. Response Reordering . . . . . . . . . . . . . . . . . . . . . 10
8. TCP Message Length Field . . . . . . . . . . . . . . . . . . 10 8. TCP Message Length Field . . . . . . . . . . . . . . . . . . 10
9. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . . . 10 9. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . 12 13.1. Normative References . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . 13 13.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Summary of Advantages and Disadvantages to using TCP Appendix A. Summary of Advantages and Disadvantages to using TCP
for DNS . . . . . . . . . . . . . . . . . . . . . . 14 for DNS . . . . . . . . . . . . . . . . . . . . . . 14
Appendix B. Changes between revisions . . . . . . . . . . . . . 15 Appendix B. Changes between revisions . . . . . . . . . . . . . 15
B.1. Changes -02 to -03 . . . . . . . . . . . . . . . . . . . 15 B.1. Changes -03 to -04 . . . . . . . . . . . . . . . . . . . 15
B.2. Changes -01 to -02 . . . . . . . . . . . . . . . . . . . 15 B.2. Changes -02 to -03 . . . . . . . . . . . . . . . . . . . 16
B.3. Changes -00 to -01 . . . . . . . . . . . . . . . . . . . 16 B.3. Changes -01 to -02 . . . . . . . . . . . . . . . . . . . 16
B.4. Changes to RFC 5966 . . . . . . . . . . . . . . . . . . . 17 B.4. Changes -00 to -01 . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 B.5. Changes to RFC 5966 . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Most DNS [RFC1034] transactions take place over UDP [RFC0768]. TCP Most DNS [RFC1034] transactions take place over UDP [RFC0768]. TCP
[RFC0793] is always used for full zone transfers (AXFR) and is often [RFC0793] is always used for full zone transfers (AXFR) and is often
used for messages whose sizes exceed the DNS protocol's original used for messages whose sizes exceed the DNS protocol's original
512-byte limit. The growing deployment of DNSSEC and IPv6 has 512-byte limit. The growing deployment of DNSSEC and IPv6 has
increased response sizes and therefore the use of TCP. The need for increased response sizes and therefore the use of TCP. The need for
increased TCP use has also been driven by the protection it provides increased TCP use has also been driven by the protection it provides
against address spoofing and therefore exploitation of DNS in against address spoofing and therefore exploitation of DNS in
skipping to change at page 4, line 34 skipping to change at page 4, line 31
before sending another query. before sending another query.
o Out-Of-Order Processing: The processing of queries concurrently o Out-Of-Order Processing: The processing of queries concurrently
and the returning of individual responses as soon as they are and the returning of individual responses as soon as they are
available, possibly out-of-order. This will most likely occur in available, possibly out-of-order. This will most likely occur in
recursive servers, however it is possible in authoritative servers recursive servers, however it is possible in authoritative servers
that, for example, have different backend data stores. that, for example, have different backend data stores.
4. Discussion 4. Discussion
In the absence of EDNS0 (Extension Mechanisms for DNS 0) (see below), In the absence of EDNS0 (Extension Mechanisms for DNS 0 [RFC6891])
the normal behaviour of any DNS server needing to send a UDP response (see below), the normal behaviour of any DNS server needing to send a
that would exceed the 512-byte limit is for the server to truncate UDP response that would exceed the 512-byte limit is for the server
the response so that it fits within that limit and then set the TC to truncate the response so that it fits within that limit and then
flag in the response header. When the client receives such a set the TC flag in the response header. When the client receives
response, it takes the TC flag as an indication that it should retry such a response, it takes the TC flag as an indication that it should
over TCP instead. retry over TCP instead.
RFC 1123 also says: RFC 1123 also says:
... it is also clear that some new DNS record types defined in the ... it is also clear that some new DNS record types defined in the
future will contain information exceeding the 512 byte limit that future will contain information exceeding the 512 byte limit that
applies to UDP, and hence will require TCP. Thus, resolvers and applies to UDP, and hence will require TCP. Thus, resolvers and
name servers should implement TCP services as a backup to UDP name servers should implement TCP services as a backup to UDP
today, with the knowledge that they will require the TCP service today, with the knowledge that they will require the TCP service
in the future. in the future.
Existing deployments of DNS Security (DNSSEC) [RFC4033] have shown Existing deployments of DNS Security (DNSSEC) [RFC4033] have shown
that truncation at the 512-byte boundary is now commonplace. For that truncation at the 512-byte boundary is now commonplace. For
example, a Non-Existent Domain (NXDOMAIN) (RCODE == 3) response from example, a Non-Existent Domain (NXDOMAIN) (RCODE == 3) response from
a DNSSEC-signed zone using NextSECure 3 (NSEC3) [RFC5155] is almost a DNSSEC-signed zone using NextSECure 3 (NSEC3) [RFC5155] is almost
invariably larger than 512 bytes. invariably larger than 512 bytes.
Since the original core specifications for DNS were written, the Since the original core specifications for DNS were written, the
Extension Mechanisms for DNS (EDNS0 [RFC6891]) have been introduced. Extension Mechanisms for DNS have been introduced. These extensions
These extensions can be used to indicate that the client is prepared can be used to indicate that the client is prepared to receive UDP
to receive UDP responses larger than 512 bytes. An EDNS0-compatible responses larger than 512 bytes. An EDNS0-compatible server
server receiving a request from an EDNS0-compatible client may send receiving a request from an EDNS0-compatible client may send UDP
UDP packets up to that client's announced buffer size without packets up to that client's announced buffer size without truncation.
truncation.
However, transport of UDP packets that exceed the size of the path However, transport of UDP packets that exceed the size of the path
MTU causes IP packet fragmentation, which has been found to be MTU causes IP packet fragmentation, which has been found to be
unreliable in many circumstances. Many firewalls routinely block unreliable in many circumstances. Many firewalls routinely block
fragmented IP packets, and some do not implement the algorithms fragmented IP packets, and some do not implement the algorithms
necessary to reassemble fragmented packets. Worse still, some necessary to reassemble fragmented packets. Worse still, some
network devices deliberately refuse to handle DNS packets containing network devices deliberately refuse to handle DNS packets containing
EDNS0 options. Other issues relating to UDP transport and packet EDNS0 options. Other issues relating to UDP transport and packet
size are discussed in [RFC5625]. size are discussed in [RFC5625].
skipping to change at page 5, line 51 skipping to change at page 5, line 46
o Authoritative server implementations MUST support TCP so that they o Authoritative server implementations MUST support TCP so that they
do not limit the size of responses to what fits in a single UDP do not limit the size of responses to what fits in a single UDP
packet. packet.
o Recursive server (or forwarder) implementations MUST support TCP o Recursive server (or forwarder) implementations MUST support TCP
so that they do not prevent large responses from a TCP-capable so that they do not prevent large responses from a TCP-capable
server from reaching its TCP-capable clients. server from reaching its TCP-capable clients.
o Stub resolver implementations (e.g., an operating system's DNS o Stub resolver implementations (e.g., an operating system's DNS
resolution library) MUST support TCP since to do otherwise would resolution library) MUST support TCP since to do otherwise would
limit their interoperability with their own clients and with limit the interoperability between their own clients and upstream
upstream servers. servers.
Regarding the choice of when to use UDP or TCP, Section 6.1.3.2 of Regarding the choice of when to use UDP or TCP, Section 6.1.3.2 of
RFC 1123 also says: RFC 1123 also says:
... a DNS resolver or server that is sending a non-zone-transfer ... a DNS resolver or server that is sending a non-zone-transfer
query MUST send a UDP query first. query MUST send a UDP query first.
This requirement is hereby relaxed. A resolver MAY elect to send This requirement is hereby relaxed. Stub resolvers and recursive
either TCP or UDP queries depending on local operational reasons. resolvers MAY elect to send either TCP or UDP queries depending on
TCP MAY be used before sending any UDP queries. If it already has an local operational reasons. TCP MAY be used before sending any UDP
open TCP connection to the server it SHOULD reuse this connection. queries. If it already has an open TCP connection to the server it
In essence, TCP ought to be considered a valid alternative transport SHOULD reuse this connection. In essence, TCP ought to be considered
to UDP, not purely a fallback option. a valid alternative transport to UDP, not purely a fallback option.
In addition it is noted that all Recursive and Authoritative servers In addition it is noted that all Recursive and Authoritative servers
MUST send responses using the same transport as the query arrived on. MUST send responses using the same transport as the query arrived on.
In the case of TCP this MUST also be the same connection. In the case of TCP this MUST also be the same connection.
6. Connection Handling 6. Connection Handling
6.1. Current practices 6.1. Current practices
Section 4.2.2 of [RFC1035] says: Section 4.2.2 of [RFC1035] says:
skipping to change at page 8, line 6 skipping to change at page 8, line 6
6.2.1. Connection Re-use 6.2.1. Connection Re-use
One perceived disadvantage to DNS over TCP is the added connection One perceived disadvantage to DNS over TCP is the added connection
setup latency, generally equal to one RTT. To amortize connection setup latency, generally equal to one RTT. To amortize connection
setup costs, both clients and servers SHOULD support connection reuse setup costs, both clients and servers SHOULD support connection reuse
by sending multiple queries and responses over a single persistent by sending multiple queries and responses over a single persistent
TCP connection. TCP connection.
When sending multiple queries over a TCP connection clients MUST take When sending multiple queries over a TCP connection clients MUST take
care to avoid Message ID collisions. In other words, they MUST not care to avoid Message ID collisions. In other words, they MUST NOT
re-use the DNS Message ID of an in-flight query. This is especially re-use the DNS Message ID of an in-flight query on the same TCP
important if the server could be performing out-of-order processing connection. This is especially important if the server could be
(see Section 7). performing out-of-order processing (see Section 7).
6.2.1.1. Query Pipelining 6.2.1.1. Query Pipelining
Due to the historical use of TCP primarily for zone transfer and Due to the historical use of TCP primarily for zone transfer and
truncated responses, no existing RFC discusses the idea of pipelining truncated responses, no existing RFC discusses the idea of pipelining
DNS queries over a TCP connection. DNS queries over a TCP connection.
In order to achieve performance on par with UDP DNS clients SHOULD In order to achieve performance on par with UDP DNS clients SHOULD
pipeline their queries. When a DNS client sends multiple queries to pipeline their queries. When a DNS client sends multiple queries to
a server, it SHOULD not wait for an outstanding reply before sending a server, it SHOULD NOT wait for an outstanding reply before sending
the next query. Clients SHOULD treat TCP and UDP equivalently when the next query. Clients SHOULD treat TCP and UDP equivalently when
considering the time at which to send a particular query. considering the time at which to send a particular query.
DNS clients will benefit from noting that DNS servers that do not It is likely that DNS servers need to process pipelined queries
both process pipelined queries concurrently and send out-of-order concurrently and also send out-of-order responses over TCP in order
responses will likely not provide performance on a par with UDP. If to provide the level of performance possible with UDP transport. If
TCP performance is of importance, clients might find it useful to use TCP performance is of importance, clients might find it useful to use
server processing times as input to server and transport selection server processing times as input to server and transport selection
algorithms. algorithms.
DNS servers (especially recursive) SHOULD expect to receive pipelined DNS servers (especially recursive) SHOULD expect to receive pipelined
queries. The server SHOULD process TCP queries concurrently, just as queries. The server SHOULD process TCP queries concurrently, just as
it would for UDP. The server SHOULD answer all pipelined queries, it would for UDP. The server SHOULD answer all pipelined queries,
even if they are sent in quick succession. The handling of responses even if they are sent in quick succession. The handling of responses
to pipelined queries is covered in Section 7. to pipelined queries is covered in Section 7.
skipping to change at page 9, line 10 skipping to change at page 9, line 4
that is being used on top of TCP, for example, if the resolver was that is being used on top of TCP, for example, if the resolver was
using TLS. It is however noted that certain primary/secondary using TLS. It is however noted that certain primary/secondary
configurations with many busy zones might need to use more than one configurations with many busy zones might need to use more than one
TCP connection for zone transfers for operational reasons. TCP connection for zone transfers for operational reasons.
Similarly, servers MAY impose limits on the number of concurrent TCP Similarly, servers MAY impose limits on the number of concurrent TCP
connections being handled for any particular client IP address or connections being handled for any particular client IP address or
subnet. These limits SHOULD be much looser than the client subnet. These limits SHOULD be much looser than the client
guidelines above, because the server does not know, for example, if a guidelines above, because the server does not know, for example, if a
client IP address belongs to a single client or is multiple resolvers client IP address belongs to a single client or is multiple resolvers
on a single machine, or multiple clients behind NAT. on a single machine, or multiple clients behind a device performing
Network Address Translation (NAT).
6.2.3. Idle Timeouts 6.2.3. Idle Timeouts
To mitigate the risk of unintentional server overload, DNS clients To mitigate the risk of unintentional server overload, DNS clients
MUST take care to minimize the idle time of established DNS-over-TCP MUST take care to minimize the idle time of established DNS-over-TCP
sessions made to any individual server. DNS clients SHOULD close the sessions made to any individual server. DNS clients SHOULD close the
TCP connection of an idle session, unless an idle timeout has been TCP connection of an idle session, unless an idle timeout has been
established using some other signalling mechanism, for example, established using some other signalling mechanism, for example,
[edns-tcp-keepalive]. [edns-tcp-keepalive].
skipping to change at page 9, line 32 skipping to change at page 9, line 27
RECOMMENDED that the default server application-level idle period be RECOMMENDED that the default server application-level idle period be
of the order of seconds, but no particular value is specified. In of the order of seconds, but no particular value is specified. In
practice, the idle period can vary dynamically, and servers MAY allow practice, the idle period can vary dynamically, and servers MAY allow
idle connections to remain open for longer periods as resources idle connections to remain open for longer periods as resources
permit. A timeout of at least a few seconds is advisable for normal permit. A timeout of at least a few seconds is advisable for normal
operations to support those clients that expect the SOA and AXFR operations to support those clients that expect the SOA and AXFR
request sequence to be made on a single connection as originally request sequence to be made on a single connection as originally
specified in [RFC1035]. Servers MAY use zero timeouts when specified in [RFC1035]. Servers MAY use zero timeouts when
experiencing heavy load or are under attack. experiencing heavy load or are under attack.
DNS messages delivered over TCP might arrive in multiple segments. A
DNS server that resets its idle timeout after receiving a single
segment might be vulnerable to a "slow read attack." For this
reason, servers SHOULD apply the idle timeout to the receipt of a
full DNS message, rather than to receipt of any part of a DNS
message.
6.2.4. Tear Down 6.2.4. Tear Down
Under normal operation clients typically initiate connection closing Under normal operation clients typically initiate connection closing
on idle connections however servers can close the connection if their on idle connections however servers can close the connection if their
local idle timeout policy is exceeded. Connections can be also local idle timeout policy is exceeded. Connections can be also
closed by either end under unusual conditions such as defending closed by either end under unusual conditions such as defending
against an attack or system failure/reboot. against an attack or system failure/reboot.
Clients SHOULD retry unanswered queries if the connection closes Clients SHOULD retry unanswered queries if the connection closes
before receiving all outstanding responses. No specific retry before receiving all outstanding responses. No specific retry
skipping to change at page 10, line 14 skipping to change at page 10, line 17
RFC 1035 is ambiguous on the question of whether TCP responses may be RFC 1035 is ambiguous on the question of whether TCP responses may be
reordered -- the only relevant text is in Section 4.2.1, which reordered -- the only relevant text is in Section 4.2.1, which
relates to UDP: relates to UDP:
Queries or their responses may be reordered by the network, or by Queries or their responses may be reordered by the network, or by
processing in name servers, so resolvers should not depend on them processing in name servers, so resolvers should not depend on them
being returned in order. being returned in order.
For the avoidance of future doubt, this requirement is clarified. For the avoidance of future doubt, this requirement is clarified.
Authoritative servers and recursive resolvers are RECOMMENDED to Authoritative servers and recursive resolvers are RECOMMENDED to
support the sending of responses in parallel and/or out-of-order, support the preparing of responses in parallel and sending them out-
regardless of the transport protocol in use. Stub and recursive of-order, regardless of the transport protocol in use. Stub and
resolvers MUST be able to process responses that arrive in a recursive resolvers MUST be able to process responses that arrive in
different order to that in which the requests were sent, regardless a different order to that in which the requests were sent, regardless
of the transport protocol in use. of the transport protocol in use.
In order to achieve performance on par with UDP, recursive resolvers In order to achieve performance on par with UDP, recursive resolvers
SHOULD process TCP queries in parallel and return individual SHOULD process TCP queries in parallel and return individual
responses as soon as they are available, possibly out-of-order. responses as soon as they are available, possibly out-of-order.
Since pipelined responses can arrive out-of-order, clients MUST match Since pipelined responses can arrive out-of-order, clients MUST match
responses to outstanding queries using the ID field and port number. responses to outstanding queries on the same TCP connection using the
Failure by clients to properly match responses to outstanding queries Message ID. If the response contains a question section the client
can have serious consequences for interoperability. MUST match the QNAME, QCLASS and QTYPE fields. Failure by clients to
properly match responses to outstanding queries can have serious
consequences for interoperability.
8. TCP Message Length Field 8. TCP Message Length Field
For reasons of efficiency, DNS clients and servers SHOULD pass the For reasons of efficiency, DNS clients and servers SHOULD pass the
two-octet length field, and the message described by that length two-octet length field, and the message described by that length
field, to the TCP layer at the same time (e.g., in a single "write" field, to the TCP layer at the same time (e.g., in a single "write"
system call) to make it more likely that all the data will be system call) to make it more likely that all the data will be
transmitted in a single TCP segment. This additionally avoids transmitted in a single TCP segment.
problems due to some DNS servers being very sensitive to timeout
conditions on receiving messages (they might abort a TCP session if This additionally avoids problems due to some DNS servers being very
the first TCP segment does not contain both the length field and the sensitive to timeout conditions on receiving messages (they might
entire message). abort a TCP session if the first TCP segment does not contain both
the length field and the entire message). Such behavior is certainly
undesirable. As described in Section 6.2.3, servers SHOULD apply
connection timeouts to the receipt of a full message and MUST NOT
close a connection simply because the first "read" from the TCP layer
does not contain the entire message.
9. TCP Fast Open 9. TCP Fast Open
This section is non-normative. This section is non-normative.
TCP Fast Open [RFC7413] (TFO) allows data to be carried in the SYN TCP Fast Open [RFC7413] (TFO) allows data to be carried in the SYN
packet, reducing the cost of re-opening TCP connections. It also packet, reducing the cost of re-opening TCP connections. It also
saves up to one RTT compared to standard TCP. saves up to one RTT compared to standard TCP.
TFO mitigates the security vulnerabilities inherent in sending data TFO mitigates the security vulnerabilities inherent in sending data
skipping to change at page 12, line 20 skipping to change at page 12, line 35
o maximum TCP connection duration o maximum TCP connection duration
No specific values are recommended for these parameters. No specific values are recommended for these parameters.
Operators are advised to familiarise themselves with the Operators are advised to familiarise themselves with the
configuration and tuning parameters available in the operating system configuration and tuning parameters available in the operating system
TCP stack. However detailed advice on this is outside the scope of TCP stack. However detailed advice on this is outside the scope of
this document. this document.
Operators of recursive servers are advised to ensure that they only Operators of recursive servers are advised to ensure that they only
accept connections from expected clients, and do not accept them from accept connections from expected clients (for example by the use of
unknown sources. In the case of UDP traffic, this will help protect an ACL), and do not accept them from unknown sources. In the case of
against reflector attacks [RFC5358] and in the case of TCP traffic it UDP traffic, this will help protect against reflection attacks
will prevent an unknown client from exhausting the server's limits on [RFC5358] and in the case of TCP traffic it will prevent an unknown
the number of concurrent connections. client from exhausting the server's limits on the number of
concurrent connections.
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Francis Dupont and Paul Vixie for The authors would like to thank Francis Dupont and Paul Vixie for
detailed review, Andrew Sullivan, Tony Finch, Stephane Bortzmeyer and detailed review, Andrew Sullivan, Tony Finch, Stephane Bortzmeyer,
the many others who contributed to the mailing list discussion. Also Joe Abley, Tatuya Jinmei and the many others who contributed to the
Liang Zhu, Zi Hu, and John Heidemann for extensive DNS-over-TCP mailing list discussion. Also Liang Zhu, Zi Hu, and John Heidemann
discussions and code. Lucie Guiraud and Danny McPherson for for extensive DNS-over-TCP discussions and code. Lucie Guiraud and
reviewing early versions of this document. We would also like to Danny McPherson for reviewing early versions of this document. We
thank all those who contributed to RFC 5966. would also like to thank all those who contributed to RFC5966.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
skipping to change at page 14, line 23 skipping to change at page 14, line 40
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, December 2014. Fast Open", RFC 7413, December 2014.
[RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting
(DNS RRL)", ISC-TN 2012-1-Draft1, April 2012. (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012.
[edns-tcp-keepalive] [edns-tcp-keepalive]
Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns- edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns-
tcp-keepalive-02 (work in progress), May 2015. tcp-keepalive-04 (work in progress), Oct 2015.
[fragmentation-considered-poisonous] [fragmentation-considered-poisonous]
Herzberg, A. and H. Shulman, "Fragmentation Considered Herzberg, A. and H. Shulman, "Fragmentation Considered
Poisonous", May 2012, <http://arxiv.org/abs/1205.4011>. Poisonous", May 2012, <http://arxiv.org/abs/1205.4011>.
Appendix A. Summary of Advantages and Disadvantages to using TCP for Appendix A. Summary of Advantages and Disadvantages to using TCP for
DNS DNS
The TCP handshake generally prevents address spoofing and, therefore, The TCP handshake generally prevents address spoofing and, therefore,
the reflection/amplification attacks which plague UDP. the reflection/amplification attacks which plague UDP.
skipping to change at page 15, line 26 skipping to change at page 15, line 44
implementations. implementations.
A more in-depth discussion of connection orientated DNS can be found A more in-depth discussion of connection orientated DNS can be found
elsewhere [Connection-Oriented-DNS]. elsewhere [Connection-Oriented-DNS].
Appendix B. Changes between revisions Appendix B. Changes between revisions
[Note to RFC Editor: please remove this section prior to [Note to RFC Editor: please remove this section prior to
publication.] publication.]
B.1. Changes -02 to -03 B.1. Changes -03 to -04
o Re-stated how messages received over TCP should be mapped to
queries.
o Added wording to cover timeouts for server side behaviour for when
receiving TCP messages.
o Added sentence to abstract stating this obsoletes RFC5966.
o Moved reference to RFC6891 earlier in Discussion section.
o Several minor wording updates to improve clarity.
o Corrected nits and updated references.
B.2. Changes -02 to -03
o Replaced certain lower case RFC2119 keywords to improve clarity. o Replaced certain lower case RFC2119 keywords to improve clarity.
o Updated section 6.2.2 to recognise requirements for concurrent o Updated section 6.2.2 to recognise requirements for concurrent
zone transfers. zone transfers.
o Changed 'client IP address' to 'client IP address or subnet' when o Changed 'client IP address' to 'client IP address or subnet' when
discussing restrictions on TCP connections from clients. discussing restrictions on TCP connections from clients.
o Added reference to edns-tcp-keepalive draft. o Added reference to edns-tcp-keepalive draft.
o Added wording to introduction to reference Appendix A and state o Added wording to introduction to reference Appendix A and state
TCP is a valid transport alternative for DNS. TCP is a valid transport alternative for DNS.
o Improved description of CPNI-TCP as a general reference source on o Improved description of CPNI-TCP as a general reference source on
TCP security related RFCs. TCP security related RFCs.
B.2. Changes -01 to -02 B.3. Changes -01 to -02
o Added more text to Introduction as background to TCP use. o Added more text to Introduction as background to TCP use.
o Added definitions of Persistent connection and Idle session to o Added definitions of Persistent connection and Idle session to
Terminology section. Terminology section.
o Separated Connection Handling section into Current Practice and o Separated Connection Handling section into Current Practice and
Recommendations. Provide more detail on current practices and Recommendations. Provide more detail on current practices and
divided Recommendations up into more granular sub-sections. divided Recommendations up into more granular sub-sections.
skipping to change at page 16, line 32 skipping to change at page 17, line 14
o Updated text on server limits on concurrent connections from a o Updated text on server limits on concurrent connections from a
particular client. particular client.
o Added text that client retry logic is outside the scope of this o Added text that client retry logic is outside the scope of this
document. document.
o Clarified that servers should answer all pipelined queries even if o Clarified that servers should answer all pipelined queries even if
sent very close together. sent very close together.
B.3. Changes -00 to -01 B.4. Changes -00 to -01
o Changed updates to obsoletes RFC 5966. o Changed updates to obsoletes RFC 5966.
o Improved text in Section 4 Transport Protocol Selection to change o Improved text in Section 4 Transport Protocol Selection to change
"TCP SHOULD NOT be used only for the transfers and as a fallback" "TCP SHOULD NOT be used only for the transfers and as a fallback"
to make the intention clearer and more consistent. to make the intention clearer and more consistent.
o Reference to TCP FASTOPEN updated now that it is an RFC. o Reference to TCP FASTOPEN updated now that it is an RFC.
o Added paragraph to say that implementations MUST NOT send the TCP o Added paragraph to say that implementations MUST NOT send the TCP
skipping to change at page 17, line 7 skipping to change at page 17, line 38
o Added Terminology section. o Added Terminology section.
o Changed should and RECOMMENDED in reference to parallel processing o Changed should and RECOMMENDED in reference to parallel processing
to SHOULD in sections 7 and 8. to SHOULD in sections 7 and 8.
o Added text to address what a server should do when a client closes o Added text to address what a server should do when a client closes
the TCP connection before pending responses are sent. the TCP connection before pending responses are sent.
o Moved the Advantages and Disadvantages section to an appendix. o Moved the Advantages and Disadvantages section to an appendix.
B.4. Changes to RFC 5966 B.5. Changes to RFC 5966
This document differs from RFC 5966 in four additions: This document differs from RFC 5966 in four additions:
1. DNS implementations are recommended not only to support TCP but 1. DNS implementations are recommended not only to support TCP but
to support it on an equal footing with UDP to support it on an equal footing with UDP
2. DNS implementations are recommended to support reuse of TCP 2. DNS implementations are recommended to support reuse of TCP
connections connections
3. DNS implementations are recommended to support pipelining and out 3. DNS implementations are recommended to support pipelining and out
 End of changes. 30 change blocks. 
74 lines changed or deleted 107 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/