DNS Transport over TCP - Implementation Requirements
draft-ietf-dnsop-5966bis-03

quot;, RFC 5966, August 2010.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.

   [RFC7230]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
              2014.

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]
              Zhu, L., Hu, Z., Heidemann, J., Wessels, D., Mankin, A.,
              and N. Somaiya, "Connection-Oriented DNS to Improve
              Privacy and Security",
              <http://www.isi.edu/~johnh/PAPERS/Zhu15b.pdf>.

Dickinson, et al.        Expires March 23, 2016                [Page 13]
Internet-Draft                DNS over TCP                September 2015

   [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, 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 RRL)", ISC-TN 2012-1-Draft1, April 2012.

   [edns-tcp-keepalive]
              Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
              edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns-
              tcp-keepalive-02 (work in progress), May 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
             DNS

   The TCP handshake generally prevents address spoofing and, therefore,
   the reflection/amplification attacks which plague 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
   IP fragmentation of TCP segments.  UDP, on the other hand, does not
   provide reassembly, which means datagrams that exceed the path MTU
   size must experience fragmentation [RFC5405].  Middleboxes are known
   to block IP fragments, leading to timeouts and forcing client
   implementations to "hunt" for EDNS0 reply size values supported by
   the network path.  Additionally, fragmentation may lead to cache
   poisoning [fragmentation-considered-poisonous].

   TCP setup costs an additional RTT compared to UDP queries.  Setup
   costs can be amortized by reusing connections, pipelining queries,
   and enabling TCP Fast Open.

   TCP imposes additional state-keeping requirements on clients and
   servers.  The use of TCP Fast Open reduces the cost of closing and
   re-opening TCP connections.

Dickinson, et al.        Expires March 23, 2016                [Page 14]
Internet-Draft                DNS over TCP                September 2015

   Long-lived TCP connections to anycast servers might be disrupted due
   to routing changes.  Clients utilizing TCP for DNS need to always be
   prepared to re-establish connections or otherwise retry outstanding
   queries.  It might also be possible for TCP Multipath [RFC6824] to
   allow a server to hand a connection over from the anycast address to
   a unicast address.

   There are many "Middleboxes" in use today that interfere with TCP
   over port 53 [RFC5625].  This document does not propose any
   solutions, other than to make it absolutely clear that TCP is a valid
   transport for DNS and support for it is a requirement for all
   implementations.

   A more in-depth discussion of connection orientated DNS can be found
   elsewhere [Connection-Oriented-DNS].

Appendix B.  Changes between revisions

   [Note to RFC Editor: please remove this section prior to
   publication.]

B.1.  Changes -02 to -03

   o  Replaced certain lower case RFC2119 keywords to improve clarity.

   o  Updated section 6.2.2 to recognise requirements for concurrent
      zone transfers.

   o  Changed 'client IP address' to 'client IP address or subnet' when
      discussing restrictions on TCP connections from clients.

   o  Added reference to edns-tcp-keepalive draft.

   o  Added wording to introduction to reference Appendix A and state
      TCP is a valid transport alternative for DNS.

   o  Improved description of CPNI-TCP as a general reference source on
      TCP security related RFCs.

B.2.  Changes -01 to -02

   o  Added more text to Introduction as background to TCP use.

   o  Added definitions of Persistent connection and Idle session to
      Terminology section.

Dickinson, et al.        Expires March 23, 2016                [Page 15]
Internet-Draft                DNS over TCP                September 2015

   o  Separated Connection Handling section into Current Practice and
      Recommendations.  Provide more detail on current practices and
      divided Recommendations up into more granular sub-sections.

   o  Add section on Idle time with new text on recommendations for
      client idle behaviour.

   o  Move TCP message field length discussion to separate section.

   o  Removed references to system calls in TFO section.

   o  Added more discussion on DoS mitigation in Security Considerations
      section.

   o  Added statement that servers MAY use 0 idle timeout.

   o  Re-stated position of TCP as an alternative to UDP in Discussion.

   o  Updated text on server limits on concurrent connections from a
      particular client.

   o  Added text that client retry logic is outside the scope of this
      document.

   o  Clarified that servers should answer all pipelined queries even if
      sent very close together.

B.3.  Changes -00 to -01

   o  Changed updates to obsoletes RFC 5966.

   o  Improved text in Section 4 Transport Protocol Selection to change
      "TCP SHOULD NOT be used only for the transfers and as a fallback"
      to make the intention clearer and more consistent.

   o  Reference to TCP FASTOPEN updated now that it is an RFC.

   o  Added paragraph to say that implementations MUST NOT send the TCP
      framing 2 byte length field in a separate packet to the DNS
      message.

   o  Added Terminology section.

   o  Changed should and RECOMMENDED in reference to parallel processing
      to SHOULD in sections 7 and 8.

   o  Added text to address what a server should do when a client closes
      the TCP connection before pending responses are sent.

Dickinson, et al.        Expires March 23, 2016                [Page 16]
Internet-Draft                DNS over TCP                September 2015

   o  Moved the Advantages and Disadvantages section to an appendix.

B.4.  Changes to RFC 5966

   This document differs from RFC 5966 in four additions:

   1.  DNS implementations are recommended not only to support TCP but
       to support it on an equal footing with UDP

   2.  DNS implementations are recommended to support reuse of TCP
       connections

   3.  DNS implementations are recommended to support pipelining and out
       of order processing of the query stream

   4.  A non-normative discussion of use of TCP Fast Open is added

Authors' Addresses

   John Dickinson
   Sinodun Internet Technologies
   Magdalen Centre
   Oxford Science Park
   Oxford  OX4 4GA
   UK

   Email: jad@sinodun.com
   URI:   http://sinodun.com

   Sara Dickinson
   Sinodun Internet Technologies
   Magdalen Centre
   Oxford Science Park
   Oxford  OX4 4GA
   UK

   Email: sara@sinodun.com
   URI:   http://sinodun.com

Dickinson, et al.        Expires March 23, 2016                [Page 17]
Internet-Draft                DNS over TCP                September 2015

   Ray Bellis
   Internet Systems Consortium, Inc
   950 Charter Street
   Redwood City  CA  94063
   USA

   Phone: +1 650 423 1200
   Email: ray@isc.org
   URI:   http://www.isc.org

   Allison Mankin
   Verisign Labs
   12061 Bluemont Way
   Reston, VA  20190
   US

   Phone: +1 703 948-3200
   Email: amankin@verisign.com

   Duane Wessels
   Verisign Labs
   12061 Bluemont Way
   Reston, VA  20190
   US

   Phone: +1 703 948-3200
   Email: dwessels@verisign.com

Dickinson, et al.        Expires March 23, 2016                [Page 18]