draft-ietf-dnsop-5966bis-04.txt   draft-ietf-dnsop-5966bis-05.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 Updates: 1035,1123 (if approved) R. Bellis
Expires: May 6, 2016 ISC Intended status: Standards Track ISC
A. Mankin Expires: June 19, 2016 A. Mankin
D. Wessels D. Wessels
Verisign Labs Verisign Labs
November 3, 2015 December 17, 2015
DNS Transport over TCP - Implementation Requirements DNS Transport over TCP - Implementation Requirements
draft-ietf-dnsop-5966bis-04 draft-ietf-dnsop-5966bis-05
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. This document obsoletes RFC5966 and therefore updates RFC1035 and
RFC1123.
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 May 6, 2016. This Internet-Draft will expire on June 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . . 6 6.1.1. Clients . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . 10 7. Response Reordering . . . . . . . . . . . . . . . . . . . . . 10
8. TCP Message Length Field . . . . . . . . . . . . . . . . . . 10 8. TCP Message Length Field . . . . . . . . . . . . . . . . . . 10
9. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . . 13 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . 13 13.1. Normative References . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . 15
Appendix B. Changes between revisions . . . . . . . . . . . . . 15 Appendix B. Changes between revisions . . . . . . . . . . . . . 16
B.1. Changes -03 to -04 . . . . . . . . . . . . . . . . . . . 15 B.1. Changes -03 to -04 . . . . . . . . . . . . . . . . . . . 16
B.2. Changes -02 to -03 . . . . . . . . . . . . . . . . . . . 16 B.2. Changes -02 to -03 . . . . . . . . . . . . . . . . . . . 16
B.3. Changes -01 to -02 . . . . . . . . . . . . . . . . . . . 16 B.3. Changes -01 to -02 . . . . . . . . . . . . . . . . . . . 17
B.4. Changes -00 to -01 . . . . . . . . . . . . . . . . . . . 17 B.4. Changes -00 to -01 . . . . . . . . . . . . . . . . . . . 17
B.5. Changes to RFC 5966 . . . . . . . . . . . . . . . . . . . 17 Appendix C. Changes to RFC5966 . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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
reflection/amplification attacks. It is now widely used in Response reflection/amplification attacks. It is now widely used in Response
Rate Limiting [RRL]. Rate Limiting [RRL1][RRL2].
Section 6.1.3.2 of [RFC1123] states: Section 6.1.3.2 of [RFC1123] states:
DNS resolvers and recursive servers MUST support UDP, and SHOULD DNS resolvers and recursive servers MUST support UDP, and SHOULD
support TCP, for sending (non-zone-transfer) queries. support TCP, for sending (non-zone-transfer) queries.
However, some implementors have taken the text quoted above to mean However, some implementors have taken the text quoted above to mean
that TCP support is an optional feature of the DNS protocol. that TCP support is an optional feature of the DNS protocol.
The majority of DNS server operators already support TCP and the The majority of DNS server operators already support TCP and the
skipping to change at page 3, line 39 skipping to change at page 3, line 40
to be considered. This document addresses these issues and presents to be considered. This document addresses these issues and presents
TCP as a valid transport alternative for DNS. It extends the content TCP as a valid transport alternative for DNS. It extends the content
of [RFC5966], with additional considerations and lessons learned from of [RFC5966], with additional considerations and lessons learned from
research, developments and implementation of TCP in DNS and in other research, developments and implementation of TCP in DNS and in other
internet protocols. internet protocols.
Whilst this document makes no specific requirements for operators of Whilst this document makes no specific requirements for operators of
DNS servers to meet, it does offer some suggestions to operators to DNS servers to meet, it does offer some suggestions to operators to
help ensure that support for TCP on their servers and network is help ensure that support for TCP on their servers and network is
optimal. It should be noted that failure to support TCP (or the optimal. It should be noted that failure to support TCP (or the
blocking of DNS over TCP at the network layer) may result in blocking of DNS over TCP at the network layer) will probably result
resolution failure and/or application-level timeouts. in resolution failure and/or application-level timeouts.
2. Requirements Terminology 2. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
o Persistent connection: a TCP connection that is not closed either o Persistent connection: a TCP connection that is not closed either
by the server after sending the first response nor by the client by the server after sending the first response nor by the client
after receiving the first response. after receiving the first response.
o Connection Reuse: the sending of multiple queries and responses o Connection Reuse: the sending of multiple queries and responses
over a single TCP connection. over a single TCP connection.
o Idle DNS-over-TCP session: Clients and servers view application o Idle DNS-over-TCP session: Clients and servers view application
level idleness differently. A DNS client considers an established level idleness differently. A DNS client considers an established
DNS-over-TCP session to be idle when it has no pending queries to DNS-over-TCP session to be idle when it has no pending queries to
skipping to change at page 5, line 33 skipping to change at page 5, line 37
The MTU most commonly found in the core of the Internet is around The MTU most commonly found in the core of the Internet is around
1500 bytes, and even that limit is routinely exceeded by DNSSEC- 1500 bytes, and even that limit is routinely exceeded by DNSSEC-
signed responses. signed responses.
The future that was anticipated in RFC 1123 has arrived, and the only The future that was anticipated in RFC 1123 has arrived, and the only
standardised UDP-based mechanism that may have resolved the packet standardised UDP-based mechanism that may have resolved the packet
size issue has been found inadequate. size issue has been found inadequate.
5. Transport Protocol Selection 5. Transport Protocol Selection
All general-purpose DNS implementations MUST support both UDP and TCP Section 6.1.3.2 of [RFC1123] is updated: All general-purpose DNS
transport. implementations MUST support both UDP and TCP transport.
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
skipping to change at page 6, line 37 skipping to change at page 6, line 40
all outstanding client requests have been satisfied. all outstanding client requests have been satisfied.
o If the server needs to close a dormant connection to reclaim o If the server needs to close a dormant connection to reclaim
resources, it should wait until the connection has been idle for a resources, it should wait until the connection has been idle for a
period on the order of two minutes. In particular, the server period on the order of two minutes. In particular, the server
should allow the SOA and AXFR request sequence (which begins a should allow the SOA and AXFR request sequence (which begins a
refresh operation) to be made on a single connection. Since the refresh operation) to be made on a single connection. Since the
server would be unable to answer queries anyway, a unilateral server would be unable to answer queries anyway, a unilateral
close or reset may be used instead of graceful close. close or reset may be used instead of graceful close.
Other more modern protocols (e.g., HTTP/1.1 [RFC7230]) have support Other more modern protocols (e.g., HTTP/1.1 [RFC7230], HTTP/2
by default for persistent TCP connections for all requests. [RFC7540]) have support by default for persistent TCP connections for
Connections are then normally closed via a 'connection close' signal all requests. Connections are then normally closed via a 'connection
from one party. close' signal from one party.
The description in [RFC1035] is clear that servers should view The description in [RFC1035] is clear that servers should view
connections as persistent (particularly after receiving an SOA), but connections as persistent (particularly after receiving an SOA), but
unfortunately does not provide enough detail for an unambiguous unfortunately does not provide enough detail for an unambiguous
interpretation of client behaviour for queries other than a SOA. interpretation of client behaviour for queries other than a SOA.
Additionally, DNS does not yet have a signalling mechanism for Additionally, DNS does not yet have a signalling mechanism for
connection timeout or close, although some have been proposed. connection timeout or close, although some have been proposed.
6.1.1. Clients 6.1.1. Clients
skipping to change at page 8, line 5 skipping to change at page 8, line 5
TCP. TCP.
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 NOT
care to avoid Message ID collisions. In other words, they MUST NOT re-use the DNS Message ID of an in-flight query on that connection in
re-use the DNS Message ID of an in-flight query on the same TCP order to avoid Message ID collisions. This is especially important
connection. This is especially important if the server could be if the server could be performing out-of-order processing (see
performing out-of-order processing (see Section 7). 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
skipping to change at page 8, line 33 skipping to change at page 8, line 33
It is likely that DNS servers need to process pipelined queries It is likely that DNS servers need to process pipelined queries
concurrently and also send out-of-order responses over TCP in order concurrently and also send out-of-order responses over TCP in order
to provide the level of performance possible with UDP transport. 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 received in quick succession. The handling of
to pipelined queries is covered in Section 7. responses to pipelined queries is covered in Section 7.
6.2.2. Concurrent connections 6.2.2. Concurrent connections
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 number of concurrent TCP connections MUST take care to minimize the number of concurrent TCP connections
made to any individual server. It is RECOMMENDED that for any given made to any individual server. It is RECOMMENDED that for any given
client/server interaction there SHOULD be no more than one connection client/server interaction there SHOULD be no more than one connection
for regular queries, one for zone transfers and one for each protocol for regular queries, one for zone transfers and one for each protocol
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
skipping to change at page 9, line 30 skipping to change at page 9, line 30
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 messages delivered over TCP might arrive in multiple segments. A
DNS server that resets its idle timeout after receiving a single DNS server that resets its idle timeout after receiving a single
segment might be vulnerable to a "slow read attack." For this segment might be vulnerable to a "slow read attack." For this
reason, servers SHOULD apply the idle timeout to the receipt of a reason, servers SHOULD reset the idle timeout on the receipt of a
full DNS message, rather than to receipt of any part of a DNS full DNS message, rather than on receipt of any part of a DNS
message. message.
6.2.4. Tear Down 6.2.4. Tear Down
Under normal operation clients typically initiate connection closing Under normal operation DNS clients typically initiate connection
on idle connections however servers can close the connection if their closing on idle connections, however DNS servers can close the
local idle timeout policy is exceeded. Connections can be also connection if their local idle timeout policy is exceeded.
closed by either end under unusual conditions such as defending Connections can be also closed by either end under unusual conditions
against an attack or system failure/reboot. such as defending against an attack or system failure/reboot.
Clients SHOULD retry unanswered queries if the connection closes DNS 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
algorithm is specified in this document. algorithm is specified in this document.
If a server finds that a client has closed a TCP session, or if the If a DNS server finds that a DNS client has closed a TCP session, or
session has been otherwise interrupted, before all pending responses if the session has been otherwise interrupted, before all pending
have been sent then the server MUST NOT attempt to send those responses have been sent then the server MUST NOT attempt to send
responses. Of course the server MAY cache those responses. those responses. Of course the DNS server MAY cache those responses.
7. Response Reordering 7. Response Reordering
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.
skipping to change at page 10, line 36 skipping to change at page 10, line 36
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 on the same TCP connection using the responses to outstanding queries on the same TCP connection using the
Message ID. If the response contains a question section the client Message ID. If the response contains a question section the client
MUST match the QNAME, QCLASS and QTYPE fields. Failure by clients to MUST match the QNAME, QCLASS and QTYPE fields. Failure by clients to
properly match responses to outstanding queries can have serious properly match responses to outstanding queries can have serious
consequences for interoperability. consequences for interoperability.
8. TCP Message Length Field 8. TCP Message Length Field
For reasons of efficiency, DNS clients and servers SHOULD pass the DNS clients and servers SHOULD pass the two-octet length field, and
two-octet length field, and the message described by that length the message described by that length field, to the TCP layer at the
field, to the TCP layer at the same time (e.g., in a single "write" same time (e.g., in a single "write" system call) to make it more
system call) to make it more likely that all the data will be likely that all the data will be transmitted in a single TCP segment.
transmitted in a single TCP segment. This is both for reasons of efficiency and to avoid problems due to
some DNS server implementations behaving undesirably when processing
TCP segments (due to a lack of clarity in previous standards). For
example, some DNS server implementations might abort a TCP session if
the first TCP segment does not contain both the length field and the
entire message.
This additionally avoids problems due to some DNS servers being very To clarify, DNS servers MUST NOT close a connection simply because
sensitive to timeout conditions on receiving messages (they might the first "read" from the TCP layer does not contain the entire DNS
abort a TCP session if the first TCP segment does not contain both message, and servers SHOULD apply the connection timeouts as
the length field and the entire message). Such behavior is certainly specified in Section 6.2.3.
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 13, line 9 skipping to change at page 13, line 9
Joe Abley, Tatuya Jinmei and the many others who contributed to the Joe Abley, Tatuya Jinmei and the many others who contributed to the
mailing list discussion. Also Liang Zhu, Zi Hu, and John Heidemann mailing list discussion. Also Liang Zhu, Zi Hu, and John Heidemann
for extensive DNS-over-TCP discussions and code. Lucie Guiraud and for extensive DNS-over-TCP discussions and code. Lucie Guiraud and
Danny McPherson for reviewing early versions of this document. We Danny McPherson for reviewing early versions of this document. We
would also like to thank all those who contributed to RFC5966. 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, DOI
August 1980. 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
and Support", STD 3, RFC 1123, October 1989. Application and Support", STD 3, RFC 1123, DOI 10.17487/
RFC1123, October 1989,
<http://www.rfc-editor.org/info/rfc1123>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005. 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, December 2006. Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008. Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<http://www.rfc-editor.org/info/rfc5155>.
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks", BCP 140, RFC 5358, Nameservers in Reflector Attacks", BCP 140, RFC 5358, DOI
October 2008. 10.17487/RFC5358, October 2008,
<http://www.rfc-editor.org/info/rfc5358>.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP
152, RFC 5625, August 2009. 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
<http://www.rfc-editor.org/info/rfc5625>.
[RFC5966] Bellis, R., "DNS Transport over TCP - Implementation [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation
Requirements", RFC 5966, August 2010. Requirements", RFC 5966, DOI 10.17487/RFC5966, August
2010, <http://www.rfc-editor.org/info/rfc5966>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/
RFC6891, April 2013,
<http://www.rfc-editor.org/info/rfc6891>.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June Protocol (HTTP/1.1): Message Syntax and Routing", RFC
2014. 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI
10.17487/RFC7540, May 2015,
<http://www.rfc-editor.org/info/rfc7540>.
13.2. Informative References 13.2. Informative References
[CPNI-TCP] [CPNI-TCP]
CPNI, "Security Assessment of the Transmission Control CPNI, "Security Assessment of the Transmission Control
Protocol (TCP)", 2009, <http://www.gont.com.ar/papers/ Protocol (TCP)", 2009, <http://www.gont.com.ar/papers/
tn-03-09-security-assessment-TCP.pdf>. tn-03-09-security-assessment-TCP.pdf>.
[Connection-Oriented-DNS] [Connection-Oriented-DNS]
Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A., Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A.,
skipping to change at page 14, line 29 skipping to change at page 14, line 48
Privacy and Security", Privacy and Security",
<http://www.isi.edu/~johnh/PAPERS/Zhu15b.pdf>. <http://www.isi.edu/~johnh/PAPERS/Zhu15b.pdf>.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405, DOI for Application Designers", BCP 145, RFC 5405, DOI
10.17487/RFC5405, November 2008, 10.17487/RFC5405, November 2008,
<http://www.rfc-editor.org/info/rfc5405>. <http://www.rfc-editor.org/info/rfc5405>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013. Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>.
[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, DOI 10.17487/RFC7413, December 2014,
<http://www.rfc-editor.org/info/rfc7413>.
[RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting [RRL1] 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, August 2014,
<http://ss.vix.su/~vixie/isc-tn-2012-1.txt>.
[RRL2] "BIND RRL", ISC Knowledge Base AA-00994, April 2012,
<https://deepthought.isc.org/article/AA-00994/0/Using-the-
Response-Rate-Limiting-Feature-in-BIND-9.10.html>.
[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-04 (work in progress), Oct 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>.
skipping to change at page 17, line 38 skipping to change at page 18, line 19
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.5. Changes to RFC 5966 Appendix C. Changes to RFC5966
This document differs from RFC 5966 in four additions: [Note to RFC Editor: please leave this section in the final
document.]
1. DNS implementations are recommended not only to support TCP but This document obsoletes [RFC5966] and differs from it in several
to support it on an equal footing with UDP respects. An overview of the most substantial changes/updates that
implementors should take note of is given below:
2. DNS implementations are recommended to support reuse of TCP 1. A Terminology section (Section 3) is added defining several new
connections concepts.
3. DNS implementations are recommended to support pipelining and out 2. Paragraph 3 of Section 5 puts TCP on a more equal footing with
of order processing of the query stream UDP than RFC5966. For example it states:
4. A non-normative discussion of use of TCP Fast Open is added 1. TCP MAY be used before sending any UDP queries.
2. TCP ought to be considered a valid alternative transport to
UDP, not purely a fallback option.
3. Section 6.2.1 adds a new recommendation that TCP connection-
reuse SHOULD be supported.
4. Section 6.2.1.1 adds a new recommendation that DNS clients
SHOULD pipeline their queries and DNS servers SHOULD process
pipelined queries concurrently.
5. Section 6.2.2 adds new recommendations on the number and usage
of TCP connections for client/server interactions.
6. Section 6.2.3 adds a new recommendation that DNS clients SHOULD
close idle sessions unless using a signalling mechanism.
7. Section 7 clarifies that servers are RECOMMENDED to prepare TCP
responses in parallel and send answers out-of-order. It also
clarifies how TCP queries and responses should be matched by
clients.
8. Section 8 adds a new recommendation about how DNS clients and
servers should handle the 2 byte message length field for TCP
messages.
9. Section 9 adds a non-normative discussion of the use of TCP Fast
Open.
10. The Section 11 adds new advice regarding DoS mitigation
techniques.
Authors' Addresses Authors' Addresses
John Dickinson John Dickinson
Sinodun Internet Technologies Sinodun Internet Technologies
Magdalen Centre Magdalen Centre
Oxford Science Park Oxford Science Park
Oxford OX4 4GA Oxford OX4 4GA
UK UK
 End of changes. 46 change blocks. 
88 lines changed or deleted 153 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/