<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced. 
    An alternate method (rfc include) is described in the references. -->

  <!-- DOMAIN NAMES - CONCEPTS AND FACILITIES -->
  <!ENTITY RFC1034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
  <!-- DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION -->
  <!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
  <!-- double hyphen in comments not allowed, ASCII escape sequence used instead -->
  <!-- Requirements for Internet Hosts &#45;&#45; Application and Support -->
  <!ENTITY RFC1123 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1123.xml">
  <!-- Common DNS Implementation Errors and Suggested Fixes -->
  <!ENTITY RFC1536 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1536.xml">
  <!-- Dynamic Updates in the Domain Name System (DNS UPDATE) -->
  <!ENTITY RFC2136 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2136.xml">
  <!-- Internet Protocol, Version 6 (IPv6) Specification -->
  <!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
  <!-- DNS Security Operational Considerations -->
  <!ENTITY RFC2541 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2541.xml">
  <!-- Extension Mechanisms for DNS (EDNS0) -->
  <!ENTITY RFC2671 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2671.xml">
  <!-- Defending TCP Against Spoofing Attacks -->
  <!ENTITY RFC4953 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4953.xml">
  <!-- TCP SYN Flooding Attacks and Common Mitigations -->
  <!ENTITY RFC4987 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4987.xml">
  <!-- ICMP Attacks against TCP -->
  <!ENTITY RFC5927 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5927.xml">
  <!-- Improving TCP's Robustness to Blind In-Window Attacks -->
  <!ENTITY RFC5961 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5961.xml">
  <!-- Child-to-Parent Synchronization in DNS -->
  <!ENTITY RFC7477 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7477.xml">
  <!-- DNS Transport over TCP - Implementation Requirements -->
  <!ENTITY RFC7766 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7766.xml">
  <!-- The edns-tcp-keepalive EDNS0 Option -->
  <!ENTITY RFC7828 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7828.xml">
  <!-- Specification for DNS over Transport Layer Security (TLS) -->
  <!ENTITY RFC7858 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7858.xml">
  <!-- Domain Name System (DNS) Cookies -->
  <!ENTITY RFC7873 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7873.xml">
  <!-- CHAIN Query Requests in DNS -->
  <!ENTITY RFC7901 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7901.xml">
  <!-- DNSSEC Roadblock Avoidance -->
  <!ENTITY RFC8027 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8027.xml">

  <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc category="bcp" docName="draft-ietf-dnsop-dns-tcp-requirements-00" ipr="trust200902">
 <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN" 
    they will automatically be output with "(if approved)" -->

 <!-- ***** FRONT MATTER ***** -->
 <front>

   <!-- The abbreviated title is used in the page header - it is only necessary if the 
        full title is longer than 39 characters -->
   <title abbrev="DNS Transport over TCP">DNS Transport over TCP - Operational Requirements</title>

   <!-- add 'role="editor"' below for the editors if appropriate -->
   <!-- Another author who claims to be an editor -->

   <author fullname="John Kristoff" initials="J.T." surname="Kristoff">
     <organization>DePaul University</organization>
     <address>
       <postal>
         <street></street>
         <city>Chicago</city>
         <region>IL</region>
         <code>60604</code>
         <country>US</country>
       </postal>
       <phone>+1 312 493 0305</phone>
       <email>jtk@depaul.edu</email>
       <uri>https://aharp.iorc.depaul.edu</uri>
     </address>
   </author>

   <author fullname="Duane Wessels" initials="D." surname="Wessels">
     <organization>Verisign</organization>
     <address>
       <postal>
         <street>12061 Bluemont Way</street>
         <city>Reston</city>
         <region>VA</region>
         <code>20190</code>
         <country>US</country>
       </postal>
       <phone>+1 703 948 3200</phone>
       <email>dwessels@verisign.com</email>
       <uri>http://verisigninc.com</uri>
     </address>
   </author>

   <date year="2017" />
   <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
        in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

   <!-- Meta-data Declarations -->

   <area>Operations and Management</area>
   <workgroup>Domain Name System Operations</workgroup>
   <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>DNS</keyword>
   <keyword>TCP</keyword>
   <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

   <abstract>
     <t>This document encourages the practice of permitting DNS messages to
     be carried over TCP on the Internet.  It also describes some of the
     consequences of this behavior and the potential operational issues
     that can arise when this best common practice is not upheld.</t>
   </abstract>
 </front>

 <middle>

   <section title="Introduction">
     <t>DNS messages may be delivered using UDP or TCP communications.
     While most DNS transactions are carried over UDP, some operators
     have been led to believe that any DNS over TCP traffic is unwanted or
     unnecessary for general DNS operation.  As usage and features have
     evolved, TCP transport has become increasingly important for correct and
     safe operation of the Internet DNS.  Reflecting modern usage, the DNS
     standards were recently updated to declare support for TCP is now a
     required part of the DNS implementation specifications in
     <xref target="RFC7766"></xref>.  This document is the formal
     requirements equivalent for the operational community, encouraging
     operators to ensure DNS over TCP communications support is on par
     with DNS over UDP communications.</t>

     <section title="Requirements Language">
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in <xref
       target="RFC2119">RFC 2119</xref>.</t>
     </section>

   </section>

   <section title="Background">

     <section title="Uneven Transport Usage and Preference">
       <t>In the original suite of DNS specifications, <xref
       target="RFC1034"></xref> and <xref target="RFC1035"></xref>
       clearly specified that DNS messages could be carried in either
       UDP or TCP, but they also made clear a preference for UDP as the
       transport for queries in the general case.  As stated in <xref
       target="RFC1035"></xref>:
       <list hangIndent="10" style="empty">
         <t>"While virtual circuits can be used for any DNS activity,
         datagrams are preferred for queries due to their lower overhead
         and better performance."</t>
       </list>
       </t>

       <t>Another early, important, and influential document,
       <xref target="RFC1123"></xref>, detailed the preference for UDP
       more explicitly:<list hangIndent="10" style="empty">
         <t>"DNS resolvers and recursive servers MUST support UDP, and
         SHOULD support TCP, for sending (non-zone-transfer) queries."
         </t>
       </list>
       and further stipulated:<list hangIndent="10" style="empty">
         <t>A name server MAY limit the resources it devotes to TCP
         queries, but it SHOULD NOT refuse to service a TCP query just
         because it would have succeeded with UDP.</t>
       </list>
       </t>

       <t>Culminating in <xref target="RFC1536"></xref>, DNS over TCP
       came to be associated primarily with the zone transfer mechanism,
       while most DNS queries and responses were seen as the dominion of
       UDP.</t>
     </section>

     <section title="Waiting for Large Messages and Reliability">
       <t>As stipulated in the original specifications, DNS messages
       over UDP were restricted to a 512-byte message size.  However,
       even while <xref target="RFC1123"></xref> made a clear preference
       for UDP, it foresaw DNS over TCP becoming more popular in the
       future:
       <list hangIndent="10" style="empty">
         <t>"[...] it is also clear that some new DNS record types
         defined in the future will contain information exceeding the
         512 byte limit that applies to UDP, and hence will require
         TCP.</t>
       </list>
       At least two new, widely anticipated developments were set to
       elevate the need for DNS over TCP transactions.  The first was
       dynamic updates defined in <xref target="RFC2136"></xref> and the
       second was the set of extensions collectively known as DNSSEC
       originally specified in <xref target="RFC2541"></xref>.  The
       former suggested "requestors who require an accurate response
       code must use TCP", while the later warned "[...] larger keys
       increase the size of KEY and SIG RRs.  This increases the chance
       of DNS UDP packet overflow and the possible necessity for using
       higher overhead TCP in responses."</t>

       <t>Yet defying some expectations, DNS over TCP remained little
       used in real traffic across the Internet.  Dynamic updates saw
       little deployment between autonomous networks.  Around the time
       DNSSEC was first defined, another new feature affecting DNS over
       UDP helped solidify its dominance for message transactions.</t>
     </section>

     <section title="EDNS0">
       <t>In 1999 the IETF published the Extension Mechanisms for DNS
       (EDNS0) in <xref target="RFC2671"></xref>.  This document
       standardized a way for communicating DNS nodes to perform
       rudimentary capabilities negotiation.  One such capability
       written into the base specification and present in every ENDS0
       compatible message is the value of the maximum UDP payload size
       the sender can support.  This unsigned 16-bit field specifies
       in bytes the maximum DNS MTU.  In practice, typical values are
       a subset of the 512 to 4096 byte range.  EDNS0 was rapidly and
       widely deployed over the next several years and numerous surveys
       have shown many systems currently support larger UDP MTUs
       <xref target="CASTRO2010"></xref>, <xref target="NETALYZR"></xref>
       with EDNS0.</t>

       <t>The natural effect of EDNS0 deployment meant large DNS
       messages would be less reliant on TCP than they might otherwise
       have been.  While a nonneglible population of DNS systems lack
       EDNS0 or may still fall back to TCP for some transactions, DNS
       over TCP transactions remain a very small fraction of overall
       DNS traffic <xref target="VERISIGN"></xref>.  Nevertheless, some
       average increase in DNS message size, the continued development
       of new DNS features and a denial of service mitigation technique
       (see <xref target="Security"></xref>) have suggested that DNS
       over TCP transactions are as important to the correct and safe
       operation of the Internet DNS as ever, if not more so.  Furthermore,
       there has been serious research that has suggested
       connection-oriented DNS transactions may provide security and
       privacy advantages over UDP transport <xref
       target="TDNS"></xref>.  In fact, <xref target="RFC7858"></xref>,
       a Standards Track document is just this sort of specification.
       Therefore, it might be desirable for network operators to avoid
       artificially inhibiting the potential utility and advances in the
       DNS such as these.</t>
     </section>

     <section title="&quot;Only Zone Tranfers Use TCP&quot;">
       <t>There are many in the DNS community who configure DNS over TCP
       services and expect DNS over TCP transactions to occur without
       interference.  However there has also been a long held belief by
       some operators, particularly for security-related reasons, that
       DNS over TCP services should be purposely limited or not provided
       at all <xref target="CHES94"></xref>, <xref
       target="DJBDNS"></xref>.  A popular meme has also held the
       imagination of some that DNS over TCP is only ever used for zone
       transfers and is generally unnecessary otherwise, with filtering
       all DNS over TCP traffic even described as a best practice.</t>

       <t>The position on restricting DNS over TCP had some
       justification given that historic implementations of DNS
       nameservers provided very little in the way of TCP connection
       management (for example see Section 6.1.2 of <xref
       target="RFC7766"></xref> for more details).  However modern
       standards and implementations are moving to align with the more
       sophisticated TCP management techniques employed by, for example,
       HTTP(S) servers and load balancers.</t>
     </section>
   </section>

   <section title="DNS over TCP Requirements">
     <t>Section 6.1.3.2 in <xref target="RFC1123" /> is updated: All
     general-purpose DNS servers MUST be able to service both UDP and
     TCP queries.
       <list hangIndent="10" style="symbols">
         <t>Authoritative servers MUST service TCP queries so that they
	 do not limit the size of responses to what fits in a single UDP
	 packet.</t>
         <t>Recursive servers (or forwarders) MUST service TCP queries
	 so that they do not prevent large responses from a TCP-capable
	 server from reaching its TCP-capable clients.</t>
       </list>
     Regarding the choice of limiting the resources a server devotes to
     queries, Section 6.1.3.2 in <xref target="RFC1123" /> also says:
       <list hangIndent="10" style="empty">
         <t>A name server MAY limit the resources it devotes to TCP
         queries, but it SHOULD NOT refuse to service a TCP query just
	 because it would have succeeded with UDP.</t>
       </list>
     This requirement is hereby updated: A name server MAY limit the
     the resources it devotes to queries, but it MUST NOT refuse to
     service a query just because it would have succeeded with another
     transport protocol.</t>

     <t> DNS over TCP filtering is considered harmful in the general
     case.  DNS resolver and server operators MUST provide DNS service
     over both UDP and TCP transports.  Likewise, network operators MUST
     allow DNS service over both UDP and TCP transports.  It must be
     acknowledged that DNS over TCP service can pose operational
     challenges that are not present when running DNS over UDP alone.
     However, it is the aim of this document to argue that the potential
     damage incurred by prohibiting DNS over TCP service is more
     detrimental to the continued utility and success of the DNS than
     when its usage is allowed.</t>
   </section>

   <section title="Network and System Considerations">
     <t>TODO: refer to IETF RFC 7766 connection handling discussion,
     various TCP hardening documents, network operator protocol and
     traffic best practices, etc.</t>
   </section>

   <section title="DNS over TCP Filtering Risks">

     <t>Networks that filter DNS over TCP risk losing access to
     significant or important pieces of the DNS name space.  For a
     variety of reasons a DNS answer may require a DNS over TCP query.
     This may include large message sizes, lack of EDNS0 support, DDoS
     mitigation techniques, or perhaps some future capability that is as
     yet unforeseen will also demand TCP transport.</t>

     <t>Even if any or all particular answers have consistently been
     returned successfully with UDP in the past, this continued behavior
     cannot be guaranteed when DNS messages are exchanged between
     autonomous systems.  Therefore, filtering of DNS over TCP is
     considered harmful and contrary to the safe and successful operation
     of the Internet.  This section enumerates some of the known risks
     we know about at the time of this writing when networks filter DNS
     over TCP.</t>

     <section title="DNS Wedgie">
       <t>Networks that filter DNS over TCP may inadvertently cause
       problems for third party resolvers as experienced by <xref
       target="TOYAMA"></xref>.  If for instance a resolver receives a
       truncated answer from a server, but if when the resolver resends
       the query using TCP and the TCP response never arrives, not only
       will full answer be unavailable, but the resolver will incur the
       full extent of TCP retransmissions and time outs.  This situation
       might place extreme strain on resolver resources.  If the nunber
       and frequency of these truncated answers are sufficiently high,
       we refer to the steady-state of lost resources as a result a "DNS"
       wedgie".  A DNS wedgie is often not easily or completely mitigated
       by the affected DNS resolver operator.</t>
     </section>

     <section title="DNS Root Zone KSK Rollover">
       <t>Recent plans for a new root zone DNSSEC KSK have highlighted
       a potential problem in retrieving the keys.<xref
       target="LEWIS"></xref>  Some packets in the KSK rollover process
       will be larger than 1280 bytes, the IPv6 minimum MTU for links
       carrying IPv6 traffic.<xref target="RFC2460"></xref>  While
       studies have shown that problems due to fragment filtering or an
       inability to generate and receive these larger messages are
       negible, any DNS server that is unable to receive large DNS over
       UDP messages or perform DNS over TCP may experience severe
       disruption of DNS service if performing DNSSEC validation.</t>
     </section>

   </section>

   <section anchor="Acknowledgements" title="Acknowledgements">
     <t>This document was initially motivated by feedback from students
     who pointed out that they were hearing contradictory information
     about filtering DNS over TCP messages.  Thanks in particular to a
     teaching colleague, JPL, who perhaps unknowingly encouraged the
     initial research into the differences of what the community has
     historically said and did.  Thanks to all the NANOG 63 attendees
     who provided feedback to an early talk on this subject.</t>

     <t>The following individuals provided an array of feedback to help
     improve this document: Sara Dickinson, Bob Harold, Tatuya Jinmei,
     and Paul Hoffman.  The authors are indebted to their contributions.
     Any remaining errors or imperfections are the sole responsbility of
     the document authors.</t>
   </section>

   <section anchor="IANA" title="IANA Considerations">
     <t>This memo includes no request to IANA.</t>
   </section>

   <section anchor="Security" title="Security Considerations">
     <t>Ironically, returning truncated DNS over UDP answers in order
     to induce a client query to switch to DNS over TCP has become
     a common response to source address spoofed, DNS denial-of-service
     attacks <xref target="RRL"></xref>.  Historically, operators have
     been wary of TCP-based attacks, but in recent years, UDP-based
     flooding attacks have proven to be the most common protocol attack
     on the DNS.  Nevertheless, a high rate of short-lived DNS
     transactions over TCP may pose challenges.  While many operators
     have provided DNS over TCP service for many years without duress,
     past experience is no guarantee of future success.</t>

     <t>DNS over TCP is not unlike many other Internet TCP services.
     TCP threats and many mitigation strategies have been well
     documented in a series of documents such as <xref
     target="RFC4953"></xref>, <xref target="RFC4987"></xref>, <xref
     target="RFC5927"></xref>, and <xref target="RFC5961"></xref>.</t>

   </section>
 </middle>

 <back>
   <!-- References split into informative and normative -->

   <!-- There are 2 ways to insert reference entries from the citation libraries:
    1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
    2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
       (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually in the same manner: by using xref elements.
    If you use the PI option, xml2rfc will, by default, try to find included files in the same
    directory as the including file. You can also define the XML_LIBRARY environment variable
    with a value containing a set of directories to search.  These can be either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

   <references title="Normative References">
     <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
     &RFC2119;

   </references>

   <references title="Informative References">
     <!-- Here we use entities that we defined at the beginning. -->

     &RFC1034;
     &RFC1035;
     &RFC1123;
     &RFC1536;
     &RFC2136;
     &RFC2460;
     &RFC2541;
     &RFC2671;
     <!-- &RFC2629; -->
     &RFC4953;
     &RFC4987;
     &RFC5927;
     &RFC5961;
     &RFC7477;
     &RFC7766;
     &RFC7828;
     &RFC7858;
     &RFC7873;
     &RFC7901;
     &RFC8027;

     <!-- A reference written by by an organization not a person. -->

     <reference anchor="CHES94">
       <front>
         <title>Firewalls and Internet Security: Repelling the Wily Hacker</title>
         <author fullname="William R. Cheswick" initials="W.R." surname="Cheswick" />
         <author fullname="Steven M. Bellovin" initials="S.M." surname="Bellovin" /> 
         <date year="1994" />
       </front>
     </reference>

     <reference anchor="DJBDNS"
                target="https://cr.yp.to/djbdns/tcp.html#why">
       <front>
         <title>When are TCP queries sent?</title>
         <author>
           <organization>D.J. Bernstein</organization>
         </author>
         <date year="2002" />
       </front> 
     </reference>

     <reference anchor="CASTRO2010">
       <front>
         <title>Understanding and preparing for DNS evolution</title>
         <author fullname="Sebastian Castro" initials="S." surname="Castro" />
         <author fullname="Min Zhang" initials="M." surname="Zhang" />
         <author fullname="Wolfgang John" initials="W." surname="John" />
         <author fullname="Duane Wessels" initials="D." surname="Wessels" />
         <author fullname="kc claffy" initials="k.c." surname="claffy" />
         <date year="2010" />
       </front>
     </reference>

     <reference anchor="NETALYZR">
       <front>
         <title>Netalyzr: Illuminating The Edge Network</title>
         <author fullname="Christian Kreibich" initials="C." surname="Kreibich" />
         <author fullname="Nicholas Weaver" initials="N." surname="Weaver" />
         <author fullname="Boris Nechaev" initials="B." surname="Nechaev" />
         <author fullname="Vern Paxson" initials="V." surname="Paxson" />
         <date year="2010" />
       </front>
     </reference>

     <reference anchor="VERISIGN">
       <front>
         <title>An Analysis of TCP Traffic in Root Server DITL Data</title>
         <author fullname="Matt Thomas" initials="M." surname="Thomas" />
         <author fullname="Duane Wessels" initials="D." surname="Wessels" />
         <date year="2014" />
       </front>
       <seriesInfo name="DNS-OARC 2014 Fall Workshop" value="Los Angeles" />
     </reference>

     <reference anchor="TDNS">
       <front>
         <title>Connection-oriented DNS to Improve Privacy and Security</title>
         <author fullname="Liang Zhu" initials="L." surname="Zhu" />
         <author fullname="John Heidemann" initials="J." surname="Heidemann" />
         <author fullname="Duane Wessels" initials="D." surname="Wessels" />
         <author fullname="Allison Mankin" initials="A." surname="Mankin" />
         <author fullname="Nikita Somaiya" initials="N." surname="Somaiya" />
         <date year="2015" />
       </front>
     </reference>

     <reference anchor="RRL">
       <front>
         <title>DNS Response Rate Limiting (DNS RRL)</title>
         <author fullname="Paul Vixie" initials="P." surname="Vixie" />
         <author fullname="Vernon Schryver" initials="V." surname="Schryver" />
         <date year="2012" month="April" />
       </front>
       <seriesInfo name="ISC-TN 2012-1" value="Draft1" />
     </reference>

     <reference anchor="LEWIS">
       <front>
         <title>2017 DNSSEC KSK Rollover</title>
         <author fullname="Edward Lewis" initials="E." surname="Lewis" />
         <date year="2017" month="May" day="8" />
       </front>
       <seriesInfo name="RIPE 74" value="Budapest, Hungary" />
     </reference>

     <reference anchor="TOYAMA">
       <front>
         <title>DNS Anomalies and Their Impacts on DNS Cache Servers</title>
         <author fullname="Katsuyasu Toyama" initials="K." surname="Toyama" />
         <author fullname="Keisuke Ishibashi" initials="K." surname="Ishibashi" />
         <author fullname="Masahiro Ishino" initials="M." surname="Ishino" />
         <author fullname="Chika Yoshimura" initials="C." surname="Yoshimura" />
         <author fullname="Kazunori Fujiwara" initials="K." surname="Fujiwara" />
         <date year="2004" />
       </front>
       <seriesInfo name="NANOG 32" value="Reston, VA USA" />
     </reference>         

   </references>

   <section title="Standards Related to DNS Transport over TCP">
     <t>This section enumerates all known IETF RFC documents that are
     currently of status standard, informational, best common practice
     or experimental and either implicitly or explicitly make
     assumptions or statements about the use of TCP as a transport for
     the DNS germane to this document.</t>

     <section title="TODO - additional, relevant RFCs">
     </section>

     <section title="IETF RFC 7477 - Child-to-Parent Synchronization in DNS">
       <t>This standards track document <xref target="RFC7477"></xref>
       specifies a RRType and protocol to signal and synchronize NS, A,
       and AAAA resource record changes from a child to parent zone.
       Since this protocol may require multiple requests and responses,
       it recommends utilizing DNS over TCP to ensure the conversation
       takes place between a consistent pair of end nodes.</t>
     </section>

     <section title="IETF RFC 7766 - DNS Transport over TCP - Implementation Requirements">
       <t>The standards track document <xref target="RFC7766"></xref>
       might be considered the direct ancestor of this operational
       requirements document.  The implementation requirements document
       codifies mandatory support for DNS over TCP in compliant DNS
       software.</t>
     </section>

     <section title="IETF RFC 7828 - The edns-tcp-keepalive EDNS0 Option">
       <t>This standards track document <xref target="RFC7828"></xref>
       defines an EDNS0 option to negotiate an idle timeout value for
       long-lived DNS over TCP connections.  Consequently, this document
       is only applicable and relevant to DNS over TCP sessions and
       between implementations that support this option.</t>
     </section>

     <section title="IETF RFC 7873 - Domain Name System (DNS) Cookies">
       <t>This standards track document <xref target="RFC7873"></xref>
       describes an EDNS0 option to provide additional protection
       against query and answer forgery.  This specification mentions
       DNS over TCP as a reasonable fallback mechanism when DNS Cookies
       are not available.  The specification does make mention of DNS
       over TCP processing in two specific situations.  In one, when a
       server receives only a client cookie in a request, the server
       should consider whether the request arrived over TCP and if so,
       it should consider accepting TCP as sufficient to authenticate
       the request and respond accordingly.  In another, when a client
       receives a BADCOOKIE reply using a fresh server cookie, the
       client should retry using TCP as the transport.</t>
     </section>

     <section title="IETF RFC 7901 - CHAIN Query Requests in DNS">
       <t>This experimental specification <xref target="RFC7901"></xref>
       describes an EDNS0 option that can be used by a security-aware
       validating resolver to request and obtain a complete DNSSEC
       validation path for any single query.  This document requires the
       use of DNS over TCP or a source IP address verified transport
       mechanism such as EDNS-COOKIE.<xref target="RFC7873"></xref></t>
     </section>

     <section title="IETF RFC 8027 - DNSSEC Roadblock Avoidance">
       <t>This document <xref target="RFC8027"></xref> details observed
       problems with DNSSEC deployment and mitigation techniques.
       Network traffic blocking and restrictions, including DNS over TCP
       messages, are highlighted as one reason for DNSSEC deployment
       issues.  While this document suggests these sorts of problems are
       due to "non-compliant infrastructure" and is of type BCP, the
       scope of the document is limited to detection and mitigation
       techniques to avoid so-called DNSSEC roadblocks.</t>
     </section>

   </section>

 </back>
</rfc>
