| < draft-ietf-dnsop-5966bis-04.txt | draft-ietf-dnsop-5966bis-06.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: July 18, 2016 A. Mankin | |||
| D. Wessels | D. Wessels | |||
| Verisign Labs | Verisign Labs | |||
| November 3, 2015 | January 15, 2016 | |||
| DNS Transport over TCP - Implementation Requirements | DNS Transport over TCP - Implementation Requirements | |||
| draft-ietf-dnsop-5966bis-04 | draft-ietf-dnsop-5966bis-06 | |||
| 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 July 18, 2016. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3 | 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 4 | |||
| 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 . . . . . . . . . . . . . . . . . . 8 | |||
| 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 . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
| 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 | 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 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 -05 to -06 . . . . . . . . . . . . . . . . . . . 16 | |||
| B.2. Changes -02 to -03 . . . . . . . . . . . . . . . . . . . 16 | B.2. Changes -04 to -05 . . . . . . . . . . . . . . . . . . . 17 | |||
| B.3. Changes -01 to -02 . . . . . . . . . . . . . . . . . . . 16 | B.3. Changes -03 to -04 . . . . . . . . . . . . . . . . . . . 17 | |||
| B.4. Changes -00 to -01 . . . . . . . . . . . . . . . . . . . 17 | B.4. Changes -02 to -03 . . . . . . . . . . . . . . . . . . . 18 | |||
| B.5. Changes to RFC 5966 . . . . . . . . . . . . . . . . . . . 17 | B.5. Changes -01 to -02 . . . . . . . . . . . . . . . . . . . 18 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | B.6. Changes -00 to -01 . . . . . . . . . . . . . . . . . . . 19 | |||
| Appendix C. Changes to RFC5966 . . . . . . . . . . . . . . . . . 19 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 | ||||
| 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]. Additionally, recent work on DNS privacy | |||
| solutions such as [DNS-over-TLS] is another motivation to re-visit | ||||
| DNS-over-TCP requirements. | ||||
| 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 49 ¶ | |||
| 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 41 ¶ | |||
| 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 11 ¶ | skipping to change at page 6, line 19 ¶ | |||
| 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. Stub resolvers and recursive | This requirement is hereby relaxed. Stub resolvers and recursive | |||
| resolvers MAY elect to send either TCP or UDP queries depending on | resolvers MAY elect to send either TCP or UDP queries depending on | |||
| local operational reasons. TCP MAY be used before sending any UDP | local operational reasons. TCP MAY be used before sending any UDP | |||
| queries. If it already has an open TCP connection to the server it | queries. If the resolver already has an open TCP connection to the | |||
| SHOULD reuse this connection. In essence, TCP ought to be considered | server it SHOULD reuse this connection. In essence, TCP ought to be | |||
| a valid alternative transport to UDP, not purely a fallback option. | considered a valid alternative transport to UDP, not purely a retry | |||
| 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 6, line 37 ¶ | skipping to change at page 6, line 46 ¶ | |||
| 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 | |||
| There is no clear guidance today in any RFC as to when a DNS client | There is no clear guidance today in any RFC as to when a DNS client | |||
| should close a TCP connection, and there are no specific | should close a TCP connection, and there are no specific | |||
| recommendations with regard to DNS client idle timeouts. However it | recommendations with regard to DNS client idle timeouts. However, at | |||
| is common practice for clients to close the TCP connection after | the time of writing, it is common practice for clients to close the | |||
| sending a single request (apart from the SOA/AXFR case). | TCP connection after sending a single request (apart from the SOA/ | |||
| AXFR case). | ||||
| 6.1.2. Servers | 6.1.2. Servers | |||
| Many DNS server implementations use a long fixed idle timeout and | Many DNS server implementations use a long fixed idle timeout and | |||
| default to a small number of TCP connections. They also offer little | default to a small number of TCP connections. They also offer little | |||
| by the way of TCP connection management options. The disadvantages | by the way of TCP connection management options. The disadvantages | |||
| of this include: | of this include: | |||
| o Operational experience has shown that long server timeouts can | o Operational experience has shown that long server timeouts can | |||
| easily cause resource exhaustion and poor response under heavy | easily cause resource exhaustion and poor response under heavy | |||
| skipping to change at page 8, line 5 ¶ | skipping to change at page 8, line 13 ¶ | |||
| 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 | |||
| 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. | |||
| 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) MUST 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 | |||
| 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 (for | |||
| example, to support concurrent transfers of multiple zones). | ||||
| 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 a device performing | on a single machine, or multiple clients behind a device performing | |||
| Network Address Translation (NAT). | Network Address Translation (NAT). | |||
| 6.2.3. Idle Timeouts | 6.2.3. Idle Timeouts | |||
| skipping to change at page 9, line 30 ¶ | skipping to change at page 9, line 39 ¶ | |||
| 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 45 ¶ | |||
| 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 reading | ||||
| data from the TCP layer (due to a lack of clarity in previous | ||||
| standards). For example, some DNS server implementations might abort | ||||
| a TCP session if the first "read" from the TCP layer 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 11, line 34 ¶ | skipping to change at page 11, line 42 ¶ | |||
| DNS services taking advantage of IP anycast [RFC4786] might need to | DNS services taking advantage of IP anycast [RFC4786] might need to | |||
| take additional steps when enabling TFO. From [RFC7413]: | take additional steps when enabling TFO. From [RFC7413]: | |||
| Servers that accept connection requests to the same server IP | Servers that accept connection requests to the same server IP | |||
| address should use the same key such that they generate identical | address should use the same key such that they generate identical | |||
| Fast Open Cookies for a particular client IP address. Otherwise a | Fast Open Cookies for a particular client IP address. Otherwise a | |||
| client may get different cookies across connections; its Fast Open | client may get different cookies across connections; its Fast Open | |||
| attempts would fall back to regular 3WHS. | attempts would fall back to regular 3WHS. | |||
| When DNS-over-TCP is a transport for DNS private exchange, as in | ||||
| [DNS-over-TLS], the implementor needs to be aware of TFO and to | ||||
| ensure that data requiring protection (e.g. data for a DNS query) is | ||||
| not accidentally transported in the clear. See [DNS-over-TLS] for | ||||
| discussion." | ||||
| 10. IANA Considerations | 10. IANA Considerations | |||
| This memo includes no request to IANA. | This memo includes no request to IANA. | |||
| 11. Security Considerations | 11. Security Considerations | |||
| Some DNS server operators have expressed concern that wider promotion | Some DNS server operators have expressed concern that wider promotion | |||
| and use of DNS over TCP will expose them to a higher risk of denial- | and use of DNS over TCP will expose them to a higher risk of denial- | |||
| of-service (DoS) attacks on TCP (both accidental and deliberate). | of-service (DoS) attacks on TCP (both accidental and deliberate). | |||
| skipping to change at page 12, line 38 ¶ | skipping to change at page 13, line 4 ¶ | |||
| 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 (for example by the use of | accept connections from expected clients (for example by the use of | |||
| an ACL), and do not accept them from unknown sources. In the case of | an ACL), and do not accept them from unknown sources. In the case of | |||
| UDP traffic, this will help protect against reflection attacks | UDP traffic, this will help protect against reflection attacks | |||
| [RFC5358] and in the case of TCP traffic it will prevent an unknown | [RFC5358] and in the case of TCP traffic it will prevent an unknown | |||
| client from exhausting the server's limits on the number of | client from exhausting the server's limits on the number of | |||
| concurrent connections. | 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, | detailed review, Andrew Sullivan, Tony Finch, Stephane Bortzmeyer, | |||
| 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, | |||
| August 1980. | DOI 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, | |||
| 793, September 1981. | RFC 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", | |||
| 4033, March 2005. | RFC 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, | |||
| October 2008. | DOI 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", | |||
| 152, RFC 5625, August 2009. | BCP 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", | |||
| 2014. | RFC 7230, DOI 10.17487/RFC7230, June 2014, | |||
| <http://www.rfc-editor.org/info/rfc7230>. | ||||
| 13.2. Informative References | [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>. | ||||
| [CPNI-TCP] | 13.2. Informative References | |||
| CPNI, "Security Assessment of the Transmission Control | ||||
| Protocol (TCP)", 2009, <http://www.gont.com.ar/papers/ | ||||
| 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., | |||
| and N. Somaiya, "Connection-Oriented DNS to Improve | and N. Somaiya, "Connection-Oriented DNS to Improve | |||
| 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 | [CPNI-TCP] | |||
| for Application Designers", BCP 145, RFC 5405, DOI | CPNI, "Security Assessment of the Transmission Control | |||
| 10.17487/RFC5405, November 2008, | Protocol (TCP)", 2009, <http://www.gont.com.ar/papers/ | |||
| <http://www.rfc-editor.org/info/rfc5405>. | tn-03-09-security-assessment-TCP.pdf>. | |||
| [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, | ||||
| "TCP Extensions for Multipath Operation with Multiple | ||||
| Addresses", RFC 6824, January 2013. | ||||
| [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP | ||||
| Fast Open", RFC 7413, December 2014. | ||||
| [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting | [DNS-over-TLS] | |||
| (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012. | Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., | |||
| and P. Hoffman, "TLS for DNS: Initiation and Performance | ||||
| Considerations", draft-ietf-dprive-dns-over-tls (work in | ||||
| progress), January 2016. | ||||
| [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-05 (work in progress), Jan 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>. | |||
| [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines | ||||
| for Application Designers", BCP 145, RFC 5405, | ||||
| DOI 10.17487/RFC5405, November 2008, | ||||
| <http://www.rfc-editor.org/info/rfc5405>. | ||||
| [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>. | ||||
| [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP | ||||
| Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, | ||||
| <http://www.rfc-editor.org/info/rfc7413>. | ||||
| [RRL1] Vixie, P. and V. Schryver, "DNS Response Rate Limiting | ||||
| (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>. | ||||
| 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. | |||
| IP fragmentation is less of a problem for TCP than it is for UDP. | IP fragmentation is less of a problem for TCP than it is for UDP. | |||
| TCP stacks generally implement Path MTU Discovery so they can avoid | TCP stacks generally implement Path MTU Discovery so they can avoid | |||
| IP fragmentation of TCP segments. UDP, on the other hand, does not | IP fragmentation of TCP segments. UDP, on the other hand, does not | |||
| provide reassembly, which means datagrams that exceed the path MTU | provide reassembly, which means datagrams that exceed the path MTU | |||
| skipping to change at page 15, line 44 ¶ | skipping to change at page 16, 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 -03 to -04 | B.1. Changes -05 to -06 | |||
| Introduction: Add reference to DNS-over-TLS | ||||
| Section 5: 's/it/the resolver/' and 's/fallback/retry/' | ||||
| Section 6.1.1: Make clear behaviour is 'at the time of writing', not | ||||
| a recommendation | ||||
| Section 6.2.1.1: Change SHOULD to MUST. | ||||
| Section 6.2.2: Clarify 'operational reasons' for zone transfers. | ||||
| Section 8: Re-word to remove reference to TCP segments. | ||||
| Section 9: Add sentence about use of TFO with DNS privacy solutions. | ||||
| B.2. Changes -04 to -05 | ||||
| Added second RRL reference to introduction | ||||
| Introduction, paragraph 5: s/may result/will probably result/ | ||||
| Section 5: Strengthened wording on update of RFC1123 | ||||
| Section 5: Added reference to HTTP/2 | ||||
| Section 6.2.1: Simplify wording of Message ID collisions | ||||
| Section 6.2.2: Clarify wording on idle timeout reset | ||||
| Section 6.2.4: Use DNS Server/client for consistency | ||||
| Section 8: Re-word to reduce confusion of timeout vs TCP reads | ||||
| Appendix C: Updated differences to RFC5966. | ||||
| B.3. Changes -03 to -04 | ||||
| o Re-stated how messages received over TCP should be mapped to | o Re-stated how messages received over TCP should be mapped to | |||
| queries. | queries. | |||
| o Added wording to cover timeouts for server side behaviour for when | o Added wording to cover timeouts for server side behaviour for when | |||
| receiving TCP messages. | receiving TCP messages. | |||
| o Added sentence to abstract stating this obsoletes RFC5966. | o Added sentence to abstract stating this obsoletes RFC5966. | |||
| o Moved reference to RFC6891 earlier in Discussion section. | o Moved reference to RFC6891 earlier in Discussion section. | |||
| o Several minor wording updates to improve clarity. | o Several minor wording updates to improve clarity. | |||
| o Corrected nits and updated references. | o Corrected nits and updated references. | |||
| B.2. Changes -02 to -03 | B.4. 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.3. Changes -01 to -02 | B.5. 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 17, line 14 ¶ | skipping to change at page 19, line 8 ¶ | |||
| 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.4. Changes -00 to -01 | B.6. 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 38 ¶ | skipping to change at page 19, line 32 ¶ | |||
| 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. 60 change blocks. | ||||
| 125 lines changed or deleted | 246 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||