| < draft-ietf-dnsop-5966bis-05.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 | |||
| Updates: 1035,1123 (if approved) R. Bellis | Updates: 1035,1123 (if approved) R. Bellis | |||
| Intended status: Standards Track ISC | Intended status: Standards Track ISC | |||
| Expires: June 19, 2016 A. Mankin | Expires: July 18, 2016 A. Mankin | |||
| D. Wessels | D. Wessels | |||
| Verisign Labs | Verisign Labs | |||
| December 17, 2015 | January 15, 2016 | |||
| DNS Transport over TCP - Implementation Requirements | DNS Transport over TCP - Implementation Requirements | |||
| draft-ietf-dnsop-5966bis-05 | 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 and therefore updates RFC1035 and | This document obsoletes RFC5966 and therefore updates RFC1035 and | |||
| RFC1123. | RFC1123. | |||
| Status of This Memo | Status of This Memo | |||
| skipping to change at page 1, line 39 ¶ | skipping to change at page 1, line 39 ¶ | |||
| 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 June 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 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 . . . . . . . . . . . . . . . . . . . . . . . 7 | 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 . . . . . . . . . . . . . . . . . . . . . . 15 | for DNS . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| Appendix B. Changes between revisions . . . . . . . . . . . . . 16 | Appendix B. Changes between revisions . . . . . . . . . . . . . 16 | |||
| B.1. Changes -03 to -04 . . . . . . . . . . . . . . . . . . . 16 | 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 . . . . . . . . . . . . . . . . . . . 17 | B.3. Changes -03 to -04 . . . . . . . . . . . . . . . . . . . 17 | |||
| B.4. Changes -00 to -01 . . . . . . . . . . . . . . . . . . . 17 | B.4. Changes -02 to -03 . . . . . . . . . . . . . . . . . . . 18 | |||
| Appendix C. Changes to RFC5966 . . . . . . . . . . . . . . . . . 18 | B.5. Changes -01 to -02 . . . . . . . . . . . . . . . . . . . 18 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 | 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 [RRL1][RRL2]. | 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 6, line 14 ¶ | 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 7, line 9 ¶ | skipping to change at page 7, line 16 ¶ | |||
| 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 30 ¶ | skipping to change at page 8, line 38 ¶ | |||
| 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 received in quick succession. The handling of | even if they are received in quick succession. The handling of | |||
| responses 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 10, line 41 ¶ | skipping to change at page 10, line 50 ¶ | |||
| 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 | |||
| DNS clients and servers SHOULD pass the two-octet length field, and | DNS clients and servers SHOULD pass the two-octet length field, and | |||
| the message described by that length field, to the TCP layer at the | the message described by that length field, to the TCP layer at the | |||
| same time (e.g., in a single "write" system call) to make it more | same time (e.g., in a single "write" system call) to make it more | |||
| likely that all the data will be transmitted in a single TCP segment. | likely that all the data will be transmitted in a single TCP segment. | |||
| This is both for reasons of efficiency and to avoid problems due to | This is both for reasons of efficiency and to avoid problems due to | |||
| some DNS server implementations behaving undesirably when processing | some DNS server implementations behaving undesirably when reading | |||
| TCP segments (due to a lack of clarity in previous standards). For | data from the TCP layer (due to a lack of clarity in previous | |||
| example, some DNS server implementations might abort a TCP session if | standards). For example, some DNS server implementations might abort | |||
| the first TCP segment does not contain both the length field and the | a TCP session if the first "read" from the TCP layer does not contain | |||
| entire message. | both the length field and the entire message. | |||
| To clarify, DNS servers MUST NOT close a connection simply because | To clarify, DNS servers MUST NOT close a connection simply because | |||
| the first "read" from the TCP layer does not contain the entire DNS | the first "read" from the TCP layer does not contain the entire DNS | |||
| message, and servers SHOULD apply the connection timeouts as | message, and servers SHOULD apply the connection timeouts as | |||
| specified in Section 6.2.3. | specified in Section 6.2.3. | |||
| 9. TCP Fast Open | 9. TCP Fast Open | |||
| This section is non-normative. | This section is non-normative. | |||
| 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 35 ¶ | 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, DOI | [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | |||
| 10.17487/RFC0768, August 1980, | DOI 10.17487/RFC0768, August 1980, | |||
| <http://www.rfc-editor.org/info/rfc768>. | <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, DOI 10.17487/RFC0793, September 1981, | RFC 793, DOI 10.17487/RFC0793, September 1981, | |||
| <http://www.rfc-editor.org/info/rfc793>. | <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, DOI 10.17487/RFC1034, November 1987, | STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, | |||
| <http://www.rfc-editor.org/info/rfc1034>. | <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, DOI 10.17487/RFC1035, | specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | |||
| November 1987, <http://www.rfc-editor.org/info/rfc1035>. | November 1987, <http://www.rfc-editor.org/info/rfc1035>. | |||
| [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - | [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - | |||
| Application and Support", STD 3, RFC 1123, DOI 10.17487/ | Application and Support", STD 3, RFC 1123, | |||
| RFC1123, October 1989, | DOI 10.17487/RFC1123, October 1989, | |||
| <http://www.rfc-editor.org/info/rfc1123>. | <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, DOI 10.17487/ | Requirement Levels", BCP 14, RFC 2119, | |||
| RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <http://www.rfc-editor.org/info/rfc2119>. | <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, DOI 10.17487/RFC4033, March 2005, | RFC 4033, DOI 10.17487/RFC4033, March 2005, | |||
| <http://www.rfc-editor.org/info/rfc4033>. | <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, DOI 10.17487/RFC4786, | Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, | |||
| December 2006, <http://www.rfc-editor.org/info/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, DOI 10.17487/RFC5155, March 2008, | Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, | |||
| <http://www.rfc-editor.org/info/rfc5155>. | <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, DOI | Nameservers in Reflector Attacks", BCP 140, RFC 5358, | |||
| 10.17487/RFC5358, October 2008, | DOI 10.17487/RFC5358, October 2008, | |||
| <http://www.rfc-editor.org/info/rfc5358>. | <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, DOI 10.17487/RFC5625, August 2009, | BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, | |||
| <http://www.rfc-editor.org/info/rfc5625>. | <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, DOI 10.17487/RFC5966, August | Requirements", RFC 5966, DOI 10.17487/RFC5966, August | |||
| 2010, <http://www.rfc-editor.org/info/rfc5966>. | 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, DOI 10.17487/ | for DNS (EDNS(0))", STD 75, RFC 6891, | |||
| RFC6891, April 2013, | DOI 10.17487/RFC6891, April 2013, | |||
| <http://www.rfc-editor.org/info/rfc6891>. | <http://www.rfc-editor.org/info/rfc6891>. | |||
| [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
| Protocol (HTTP/1.1): Message Syntax and Routing", RFC | Protocol (HTTP/1.1): Message Syntax and Routing", | |||
| 7230, DOI 10.17487/RFC7230, June 2014, | RFC 7230, DOI 10.17487/RFC7230, June 2014, | |||
| <http://www.rfc-editor.org/info/rfc7230>. | <http://www.rfc-editor.org/info/rfc7230>. | |||
| [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext | [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext | |||
| Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI | Transfer Protocol Version 2 (HTTP/2)", RFC 7540, | |||
| 10.17487/RFC7540, May 2015, | DOI 10.17487/RFC7540, May 2015, | |||
| <http://www.rfc-editor.org/info/rfc7540>. | <http://www.rfc-editor.org/info/rfc7540>. | |||
| 13.2. Informative References | 13.2. Informative References | |||
| [CPNI-TCP] | ||||
| 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>. | |||
| [CPNI-TCP] | ||||
| CPNI, "Security Assessment of the Transmission Control | ||||
| Protocol (TCP)", 2009, <http://www.gont.com.ar/papers/ | ||||
| tn-03-09-security-assessment-TCP.pdf>. | ||||
| [DNS-over-TLS] | ||||
| 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] | ||||
| Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The | ||||
| edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns- | ||||
| tcp-keepalive-05 (work in progress), Jan 2015. | ||||
| [fragmentation-considered-poisonous] | ||||
| Herzberg, A. and H. Shulman, "Fragmentation Considered | ||||
| Poisonous", May 2012, <http://arxiv.org/abs/1205.4011>. | ||||
| [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, | |||
| 10.17487/RFC5405, November 2008, | DOI 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, DOI 10.17487/RFC6824, January 2013, | Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, | |||
| <http://www.rfc-editor.org/info/rfc6824>. | <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, DOI 10.17487/RFC7413, December 2014, | Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, | |||
| <http://www.rfc-editor.org/info/rfc7413>. | <http://www.rfc-editor.org/info/rfc7413>. | |||
| [RRL1] 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, August 2014, | (DNS RRL)", ISC-TN 2012-1-Draft1, August 2014, | |||
| <http://ss.vix.su/~vixie/isc-tn-2012-1.txt>. | <http://ss.vix.su/~vixie/isc-tn-2012-1.txt>. | |||
| [RRL2] "BIND RRL", ISC Knowledge Base AA-00994, April 2012, | [RRL2] "BIND RRL", ISC Knowledge Base AA-00994, April 2012, | |||
| <https://deepthought.isc.org/article/AA-00994/0/Using-the- | <https://deepthought.isc.org/article/AA-00994/0/Using-the- | |||
| Response-Rate-Limiting-Feature-in-BIND-9.10.html>. | Response-Rate-Limiting-Feature-in-BIND-9.10.html>. | |||
| [edns-tcp-keepalive] | ||||
| Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The | ||||
| edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns- | ||||
| tcp-keepalive-04 (work in progress), Oct 2015. | ||||
| [fragmentation-considered-poisonous] | ||||
| Herzberg, A. and H. Shulman, "Fragmentation Considered | ||||
| Poisonous", May 2012, <http://arxiv.org/abs/1205.4011>. | ||||
| Appendix A. Summary of Advantages and Disadvantages to using TCP for | Appendix A. Summary of Advantages and Disadvantages to using TCP for | |||
| DNS | DNS | |||
| The TCP handshake generally prevents address spoofing and, therefore, | The TCP handshake generally prevents address spoofing and, therefore, | |||
| the reflection/amplification attacks which plague UDP. | the reflection/amplification attacks which plague UDP. | |||
| 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 16, line 22 ¶ | 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 42 ¶ | 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 | |||
| End of changes. 35 change blocks. | ||||
| 71 lines changed or deleted | 127 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/ | ||||