<?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">
  <!-- Transport Layer Security (TLS) Session Resumption without Server-Side State-->
  <!ENTITY RFC5077 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5077.xml">
  <!-- ICMP Attacks against TCP -->
  <!ENTITY RFC5927 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5927.xml">
  <!-- DNS Zone Transfer Protocol (AXFR) -->
  <!ENTITY RFC5936 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5936.xml">
  <!-- Improving TCP's Robustness to Blind In-Window Attacks -->
  <!ENTITY RFC5961 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5961.xml">
  <!-- AS112 Nameserver Operations -->
  <!ENTITY RFC6304 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6304.xml">
  <!-- Multicast DNS -->
  <!ENTITY RFC6762 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6762.xml">
  <!-- Extension Mechanisms for DNS (EDNS (0)) -->
  <!ENTITY RFC6891 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6891.xml">
  <!-- Architectural Considerations on Application Features in the DNS -->
  <!ENTITY RFC6950 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6950.xml">
  <!-- TCP Fast Open -->
  <!ENTITY RFC7413 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7413.xml">
  <!-- Child-to-Parent Synchronization in DNS -->
  <!ENTITY RFC7477 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7477.xml">
  <!-- Root Name Service Requirements -->
  <!ENTITY RFC7720 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7720.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">
  <!-- TLS False Start -->
  <!ENTITY RFC7918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7918.xml">
  <!-- DNSSEC Roadblock Avoidance -->
  <!ENTITY RFC8027 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8027.xml">
  <!-- DNS over DTLS -->
  <!ENTITY RFC8094 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8094.xml">
  <!-- DNS-Based Authentication for S/MIME -->
  <!ENTITY RFC8162 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8162.xml">
  <!-- DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look? -->
  <!ENTITY RFC8324 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8324.xml">
  <!-- Padding Policies for Extension Mechanisms for DNS (EDNS(0)) -->
  <!ENTITY RFC8467 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8467.xml">
  <!-- Yeti DNS Testbed -->
  <!ENTITY RFC8483 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8483.xml">
  <!-- DNS Queries over HTTPS (DoH) -->
  <!ENTITY RFC8484 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8484.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-03" ipr="trust200902" updates="1123">
 <!-- 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="2019" />
   <!-- 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 considers the consequences
     with this form of DNS communication 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">
     <t>The curious state of disagreement in operational best practices and
     guidance for DNS transport protocols derives from conflicting messages
     operators have gotten from other operators, implementors, and even the
     IETF.  Sometimes these mixed signals have been explicit, on other
     occasions they have suspiciously implicit.  Here we summarize our
     interpretation of the storied and conflicting history that has brought
     us to this document.</t>

     <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>In the original specifications, the maximum DNS over UDP message
       size was enshrined at 512 bytes.  However, even while
       <xref target="RFC1123"></xref> made a clear preference for UDP, it
       foresaw DNS over TCP becoming more popular in the future to overcome
       this limitation:<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>
       </t>

       <t>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 helped solidify UDP's
       transport 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> (superseded in 2013 by
       an update in <xref target="RFC6891"></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 (possibly fragmented) DNS message size a
       node is capable of receiving.  In practice, typical values are
       a subset of the 512 to 4096 byte range.  EDNS0 became
       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 DNS messages
       larger than 512 bytes would be less reliant on TCP than they
       might otherwise have been.  While a non-negligible 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>.</t>
     </section>

     <section title="Fragmentation and Truncation">
       <t>Although EDNS0 provides a way for endpoints to signal support for
       DNS messages exceeding 512 bytes, the realities of a diverse and
       inconsistently deployed Internet may result in some large messages
       being unable to reach their destination.  Any IP datagram whose size
       exceeds the MTU of a link it transits will be fragmented and then
       reassembled by the receiving host.  Unfortunately, it is not uncommon
       for middleboxes and firewalls to block IP fragments.  If one or more
       fragments do not arrive, the application does not receive the message
       and the request times out.</t>

       <t>For IPv4-connected hosts, the de-facto MTU is often the Ethernet
       payload size of 1500 bytes.  This means that the largest unfragmented
       UDP DNS message that can be sent over IPv4 is likely 1472 bytes.  For
       IPv6, the situation is a little more complicated.  First, IPv6 headers
       are 40 bytes (versus 20 without option in IPv4).  Second, it seems as
       though some people have mis-interpreted IPv6's required minimum MTU of
       1280 as a required maximum.  Third, fragmentation in IPv6 can only be
       done by the host originating the datagram.  The need to fragment is
       conveyed in an ICMPv6 "packet too big" message.  The originating host
       indicates a fragmented datagram with IPv6 extension headers.
       Unfortunately, it is quite common for both ICMPv6 and IPv6 extension
       headers to be blocked by middleboxes.  According to
       <xref target="HUSTON"/> some 35%<!-- 3,592 / 10,115 --> of IPv6-capable
       recursive resolvers are unable to receive a fragmented IPv6 packet.</t>

       <t>The practical consequence of all this is that DNS requestors
       must be prepared to retry queries with different EDNS0 maximum
       message size values.  Administrators of BIND are likely to be 
       familiar with seeing "success resolving ... after reducing the
       advertised EDNS0 UDP packet size to 512 octets" messages in their
       system logs.</t>

       <t>Often, reducing the EDNS0 UDP packet size leads to a
       successful response.  That is, the necessary data fits within the
       smaller message size.  However, when the data does not fit, the
       server sets the truncated flag in its response, indicating the
       client should retry over TCP to receive the whole response.  This
       is undesirable from the client's point of view because it adds
       more latency, and potentially undesirable from the server's point
       of view due to the increased resource requirements of TCP.
       <!-- TODO maybe there is a better way to put that? --></t>

       <t>The issues around fragmentation, truncation, and TCP are
       driving certain implementation and policy decisions in the DNS.
       Notably, Cloudflare implemented what it calls "DNSSEC black lies"
       <xref target="CLOUDFLARE"/> and uses ECDSA algorithms, such that
       their signed responses fit easily in 512 bytes.  The KSK Rollover
       design team <xref target="DESIGNTEAM"/> spent a lot of time
       thinking and worrying about response sizes.  There is growing
       sentiment in the DNSSEC community that RSA key sizes beyond
       2048-bits are impractical and that critical infrastructure zones
       should transition to elliptic curve algorithms to keep response
       sizes manageable.</t>
     </section>

     <section title="&quot;Only Zone Transfers Use TCP&quot;">
       <t>Today, the majority of the DNS community expects, or at least
       has a desire, to see 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>An average increase in DNS message size,<!--XXX: cite needed-->
     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, we now believe it is undesirable for network operators to
     artificially inhibit the potential utility and advances in the DNS
     such as these.</t>

     <t>TODO: I think the text below needs some work/discussion
     because 7766 already updated 1123 in a very similar way except
     that 7766 speaks of "implement" and this one speaks of "service".
     1123 speaks of "support" and doesn't distinguish between
     implement/service.</t>

     <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>Filtering of DNS over TCP 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,
     and vice-versa.  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>This section describes measures that systems and applications
   can take to optimize performance over TCP and to protect themselves
   from TCP-based resource exhaustion and attacks.</t>

     <section title="Connection Admission">

       <t>The SYN flooding attack is a denial-of-service method
       affecting hosts that run TCP server processes <xref
       target="RFC4987"/>.  This attack can be very effective if
       not mitigated.  One of the most effective mitigation techniques
       is SYN cookies, which allows the server to avoid allocating
       any state until the successful completion of the three-way
       handshake.</t>

       <t>Services not intended for use by the public Internet,
       such as most recursive name servers, SHOULD be protected
       with access controls.  Ideally these controls are placed in
       the network, well before before any unwanted TCP packets can
       reach the DNS server host or application.  If this is not
       possible, the controls can be placed in the application
       itself.  In some situations (e.g. attacks) it may be necessary
       to deploy access controls for DNS services that should
       otherwise be globally reachable.</t>

       <t>The FreeBSD operating system has an "accept filter" feature
       that postpones delivery of TCP connections to applications
       until a complete, valid request has been received.  The
       dns_accf(9) filter ensures that a valid DNS message is
       received.  If not, the bogus connection never reaches the
       application.  Applications must be coded and configured to
       make use of this filter.</t>

       <t>Per <xref target="RFC7766"/>, applications and administrators
       are advised to remember that TCP MAY be used before sending
       any UDP queries.  Networks and applications MUST NOT be configured
       to refuse TCP queries that were not preceded by a UDP query.</t>

       <t>TCP Fast Open <xref target="RFC7413"/> (TFO) allows TCP
       clients to shorten the handshake for subsequent connections
       to the same server.  TFO saves one round-trip time in the
       connection setup.  DNS servers SHOULD enable TFO when possible.
       Furthermore, DNS servers clustered behind a single service
       address (e.g., anycast or load-balancing), SHOULD use the
       same TFO server key on all instances.</t>

       <t>DNS clients SHOULD also enable TFO when possible.  Currently,
       on some operating systems it is not implemented or disabled by default.
       <xref target="WIKIPEDIA_TFO"/> describes applications and operating systems
       that support TFO.</t>

     </section>

     <section title="Connection Management">

       <t>Since host memory for TCP state is a finite resource, DNS
       servers MUST actively manage their connections.  Applications
       that do not actively manage their connections
       can encounter resource exhaustion leading to denial of
       service.  For DNS, as in other protocols, there is a tradeoff
       between keeping connections open for potential future use and
       the need to free up resources for new connections that will arrive.</t>

       <t>DNS server software SHOULD provide a configurable limit
       on the total number of established TCP connections.  If the
       limit is reached, the application is expected to either close
       existing (idle) connections or refuse new connections.
       Operators SHOULD ensure the limit is configured appropriately
       for their particular situation.</t>

       <t>DNS server software MAY provide a configurable limit on
       the number of established connections per source IP address
       or subnet.  This can be used to ensure that a single or small
       set of users can not consume all TCP resources and deny
       service to other users.  Operators SHOULD ensure this limit
       is configured appropriately, based on their number of diversity
       of users.</t>

       <t>DNS server software SHOULD provide a configurable timeout
       for idle TCP connections.  For very busy name servers this
       might be set to a low value, such as a few seconds.  For
       less busy servers it might be set to a higher value, such
       as tens of seconds.  DNS clients and servers SHOULD signal
       their timeout values using the edns-tcp-keepalive option
       <xref target="RFC7828"/>.</t>

       <t>DNS server software MAY provide a configurable limit on
       the number of transactions per TCP connection. This document
       does not offer advice on particular values for such a
       limit.</t>

       <t>Similarly, DNS server software MAY provide a configurable
       limit on the total duration of a TCP connection.  This
       document does not offer advice on particular values for such
       a limit.</t>

       <t>Since clients may not be aware of server-imposed limits,
       clients utilizing TCP for DNS need to always be prepared to
       re-establish connections or otherwise retry outstanding
       queries.</t> <!-- language lifted from RFC7766 -->

     </section>

     <section title="Connection Termination">

       <t>In general, it is preferable for clients to initiate the
       close of a TCP connection.  The TCP peer that initiates a
       connection close retains the socket in the TIME_WAIT state
       for some amount of time, possibly a few minutes.  On a busy
       server, the accumulation of many sockets in TIME_WAIT can
       cause performance problems or even denial of service.</t>

       <t>On systems where large numbers of sockets in TIME_WAIT
       are observed, it may be beneficial to tune the local TCP
       parameters.  For example, the Linux kernel provides a number
       of "sysctl" parameters related to TIME_WAIT, such as
       net.ipv4.tcp_fin_timeout, net.ipv4.tcp_tw_recycle, and
       net.ipv4.tcp_tw_reuse.  In extreme cases, implementors and
       operators of very busy servers may find it necessary to
       utilize the SO_LINGER socket option (<xref target="Stevens"/> Section
       7.5) with a value of zero so that the server doesn't accumulate
       TIME_WAIT sockets.</t>

     </section>

   </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>For example, <xref target="RFC7901"/> describes a latency-avoiding
     technique that sends extra data in DNS responses.  This makes
     responses larger and potentially increases the risk of DDoS reflection
     attacks.  The specification mandates the use of TCP or DNS Cookies
     (<xref target="RFC7873"/>).</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 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 number
       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
       negligible, 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>

       <t>TODO: Is this "overcome by events" now?  We've had 1414
       byte DNSKEY responses at the three ZSK rollover periods since
       KSK-2017 became published in the root zone.</t>
     </section>

     <section title="DNS-over-TLS">
       <t>DNS messages may be sent over TLS to provide privacy
       between stubs and recursive resolvers. <xref target="RFC7858"/>
       is a standards track document describing how this works.
       Although it utilizes TCP port 853 instead of port 53, this
       document applies equally well to DNS-over-TLS.  Note, however,
       DNS-over-TLS is currently only defined between stubs and
       recursives.</t>

       <t>The use of TLS places even strong operational burdens
       on DNS clients and servers.  Cryptographic functions for
       authentication and encryption require additional processing.
       Unoptimized connection setup takes two additional round-trips
       compared to TCP, but can be reduced with Fast TLS connection
       resumption <xref target="RFC5077"/> and TLS False Start <xref
       target="RFC7918"/>.</t>
     </section>

   </section>

   <section title="Logging and Monitoring">
     <t>Developers of applications that log or monitor DNS are
     advised to not ignore TCP because it is rarely used or because
     it is hard to process.  Operators are advised to ensure that
     their monitoring and logging applications properly capture
     DNS-over-TCP messages.  Otherwise, attacks, exfiltration
     attempts, and normal traffic may go undetected.</t>

     <t>DNS messages over TCP are in no way guaranteed to arrive
     in single segments.  In fact, a clever attacker may attempt
     to hide certain messages by forcing them over very small TCP
     segments.  Applications that capture network packets (e.g.,
     with libpcap) should be prepared to implement and perform full
     TCP segment reassembly.  dnscap <xref target="dnscap"/> is an
     open-source example of a DNS logging program that implements
     TCP reassembly.</t>

     <t>Developers should also keep in mind connection reuse,
     pipelining, and out-of-order responses when building and testing
     DNS monitoring applications.</t>
   </section>

   <section anchor="Acknowledgments" title="Acknowledgments">
     <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 responsibility 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>

   <section anchor="Privacy" title="Privacy Considerations">
     <t>TODO: Does this document warrant privacy considerations?</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;
     &RFC5077;
     &RFC5927;
     &RFC5936;
     &RFC5961;
     &RFC6304;
     &RFC6762;
     &RFC6891;
     &RFC6950;
     &RFC7413;
     &RFC7477;
     &RFC7720;
     &RFC7766;
     &RFC7828;
     &RFC7858;
     &RFC7873;
     &RFC7901;
     &RFC7918;
     &RFC8027;
     &RFC8094;
     &RFC8162;
     &RFC8324;
     &RFC8467;
     &RFC8483;
     &RFC8484;

     <!-- 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" target="https://ripe74.ripe.net/presentations/25-RIPE74-lewis-submission.pdf">
       <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>         

     <reference anchor="HUSTON" target="https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/">
	<front>
	  <title>Dealing with IPv6 fragmentation in the DNS</title>
	  <author fullname="Geoff Huston" initials="G." surname="Huston" />
	  <date year="2017" month="August" day="22"/>
	</front>
	<format type="HTML" target="https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/"/>
     </reference>

     <reference anchor="CLOUDFLARE" target="https://blog.cloudflare.com/black-lies/">
	<front>
	  <title>Economical With The Truth: Making DNSSEC Answers Cheap</title>
	  <author fullname="Dani Grant" initials="D." surname="Grant">
	    <organization>Cloudflare</organization>
	  </author>
	  <date year="2016" month="June" day="24"/>
	</front>
	<format type="HTML" target="https://blog.cloudflare.com/black-lies/"/>
     </reference>

     <reference anchor="DESIGNTEAM" target="https://www.iana.org/reports/2016/root-ksk-rollover-design-20160307.pdf">
	<front>
	  <title>Root Zone KSK Rollover Plan</title>
	  <author>
	    <organization>Design Team Report</organization>
	  </author>
	  <date year="2015" month="December" day="18"/>
	</front>
	<format type="PDF" target="https://www.iana.org/reports/2016/root-ksk-rollover-design-20160307.pdf"/>
     </reference>

     <reference anchor="WIKIPEDIA_TFO" target="https://en.wikipedia.org/wiki/TCP_Fast_Open">
	<front>
	  <title>TCP Fast Open</title>
	  <author>
	    <organization>Wikipedia</organization>
	  </author>
	  <date year="2018" month="May" day="4"/>
	</front>
     </reference>

     <reference anchor="Stevens">
	<front>
	  <title>UNIX Network Programming Volume 1, Third Edition: The Sockets Networking API</title>
	  <author fullname="W. Richard Stevens" initials="W.R." surname="Stevens"/>
          <author fullname="Bill Fenner" initials="B." surname="Fenner"/>
          <author fullname="Andrew M. Rudoff" initials="A.M." surname="Rudoff"/>
	  <date year="2003" month="November" day="21"/>
	</front>
     </reference>

     <reference anchor="dnscap" target="https://www.dns-oarc.net/tools/dnscap">
	<front>
	  <title>DNSCAP</title>
	  <author>
	    <organization>DNS-OARC</organization>
	  </author>
	  <date year="2018" month="May" day="7"/>
	</front>
     </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 5936 - DNS Zone Transfer Protocol (AXFR)">
       <t>The <xref target="RFC5936"></xref> standards track document
       provides a detailed specification for the zone transfer protocol,
       as originally outlined in the early DNS standards.  AXFR operation
       is limited to TCP and not specified for UDP.  This document
       discusses TCP usage at length.</t>
     </section>

     <section title="IETF RFC 6304 - AS112 Nameserver Operations">
       <t><xref target="RFC6304"></xref> is an informational document
       enumerating the requirements for operation of AS112 project DNS
       servers.  New AS112 nodes are tested for their ability to provide
       service on both UDP and TCP transports, with the implication that
       TCP service is an expected part of normal operations.</t>
     </section>

     <section title="IETF RFC 6762 - Multicast DNS">
       <t>This standards track document <xref target="RFC6762"></xref> the
       TC bit is deemed to have essentially the same meaning as described
       in the original DNS specifications.  That is, if a response with the
       TCP bit set is receiver "[...] the querier SHOULD reissue its query
       using TCP in order to receive the larger response."</t>
     </section>

     <section title="IETF RFC 6950 - Architectural Considerations on Application Features in the DNS">
       <t>An informational document <xref target="RFC6950"></xref> that draws
       attention to large data in the DNS.  TCP is referenced in the
       context as a common fallback mechnanism and counter to some spoofing
       attacks.</t>
     </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 7720 - DNS Root Name Service Protocol and Deployment Requirements">
       <t>This best current practice<xref target="RFC7720"></xref>
       declares root name service "MUST support UDP [RFC768] and TCP
       [RFC793] transport of DNS queries and responses."</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 7858 - Specification for DNS over Transport Layer Security (TLS)">
       <t>This standards track document <xref target="RFC7858"></xref>
       defines a method for putting DNS messages into a TCP-based
       encrypted channel using TLS.  This specification is noteworthy
       for explicitly targetting the stub-to-recursive traffic, but
       does not preclude its application from recursive-to-authoritative
       traffic.</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 title="IETF RFC 8094 - DNS over Datagram Transport Layer Security (DTLS)">
       <t>This experimental specification <xref target="RFC8094"></xref>
       details a protocol that uses a datagram transport (UDP), but
       stipulates that "DNS clients and servers that implement DNS over
       DTLS MUST also implement DNS over TLS in order to provide privacy
       for clients that desire Strict Privacy [...]".  This requirement
       implies DNS over TCP must be supported in case the message size
       is larger than the path MTU.</t>
     </section>

     <section title="IETF RFC 8162 - Using Secure DNS to Associate Certificates with Domain Names for S/MIME">
       <t>This experimental specification <xref target="RFC8162"></xref>
       describes a technique to authenticate user X.509 certificates
       in an S/MIME system via the DNS.  The document points out that
       the new experimental resource record types are expected to carry
       large payloads, resulting in the suggestion that "applications
       SHOULD use TCP -- not UDP -- to perform queries for the SMIMEA
       resource record."</t>
     </section>

     <section title="IETF RFC 8324 - DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?">
       <t>An informational document <xref target="RFC8324"></xref> that
       briefly discusses the common role and challenges of DNS over TCP
       throughout the history of DNS.</t>
     </section>

     <section title="IETF RFC 8467 - Padding Policies for Extension Mechanisms for DNS (EDNS(0))">
       <t>An experimental document <xref target="RFC8467"></xref>
       reminds implementers to consider the underlying transport
       protocol (e.g. TCP) when calculating the padding length when
       artificially increasing the DNS message size with an EDNS(0)
       padding option.</t>
     </section>

     <section title="IETF RFC 8483 - Yeti DNS Testbed">
       <t>This informational document <xref target="RFC8483"></xref>
       describes a testbed environment that highlights some DNS over TCP
       behaviors, including issues involving packet fragmentation and
       operational requirements for TCP stream assembly in order to
       conduct DNS measurement and analysis.</t>
     </section>

     <section title="IETF RFC 8484 - DNS Queries over HTTPS (DoH)">
       <t>This standards track document <xref target="RFC8484"></xref>
       defines a protocol for sending DNS queries and responses over
       HTTPS.  This specification assumes TLS and TCP for the underlying
       security and transport layers respectively.  Self-described as a
       a technique that more closely resembles a tunneling mechanism,
       DoH nevertheless likely implies DNS over TCP in some sense if not
       directly.</t>
     </section>
 
   </section>

 </back>
</rfc>
