doc: Add RFC documents

1 files changed, 1576 insertions, 0 deletions

diff --git a/doc/rfc/rfc9210.txt b/doc/rfc/rfc9210.txt
new file mode 100644
index 0000000..06a3db9
--- /dev/null
+++ b/doc/rfc/rfc9210.txt
@@ -0,0 +1,1576 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                       J. Kristoff
+Request for Comments: 9210                                 Dataplane.org
+BCP: 235                                                      D. Wessels
+Updates: 1123, 1536                                             Verisign
+Category: Best Current Practice                               March 2022
+ISSN: 2070-1721
+
+
+           DNS Transport over TCP - Operational Requirements
+
+Abstract
+
+   This document updates RFCs 1123 and 1536.  This document requires the
+   operational practice of permitting DNS messages to be carried over
+   TCP on the Internet as a Best Current Practice.  This operational
+   requirement is aligned with the implementation requirements in RFC
+   7766.  The use of TCP includes both DNS over unencrypted TCP as well
+   as over an encrypted TLS session.  The document also considers the
+   consequences of this form of DNS communication and the potential
+   operational issues that can arise when this Best Current Practice is
+   not upheld.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9210.
+
+Copyright Notice
+
+   Copyright (c) 2022 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Requirements Language
+   2.  History of DNS over TCP
+     2.1.  Uneven Transport Usage and Preference
+     2.2.  Waiting for Large Messages and Reliability
+     2.3.  EDNS(0)
+     2.4.  Fragmentation and Truncation
+     2.5.  "Only Zone Transfers Use TCP"
+     2.6.  Reuse, Pipelining, and Out-of-Order Processing
+   3.  DNS-over-TCP Requirements
+   4.  Network and System Considerations
+     4.1.  Connection Establishment and Admission
+     4.2.  Connection Management
+     4.3.  Connection Termination
+     4.4.  DNS over TLS
+     4.5.  Defaults and Recommended Limits
+   5.  DNS-over-TCP Filtering Risks
+     5.1.  Truncation, Retries, and Timeouts
+     5.2.  DNS Root Zone KSK Rollover
+   6.  Logging and Monitoring
+   7.  IANA Considerations
+   8.  Security Considerations
+   9.  Privacy Considerations
+   10. References
+     10.1.  Normative References
+     10.2.  Informative References
+   Appendix A.  RFCs Related to DNS Transport over TCP
+     A.1.  RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
+     A.2.  RFC 1536 - Common DNS Implementation Errors and Suggested
+            Fixes
+     A.3.  RFC 1995 - Incremental Zone Transfer in DNS
+     A.4.  RFC 1996 - A Mechanism for Prompt Notification of Zone
+            Changes (DNS NOTIFY)
+     A.5.  RFC 2181 - Clarifications to the DNS Specification
+     A.6.  RFC 2694 - DNS extensions to Network Address Translators
+            (DNS_ALG)
+     A.7.  RFC 3225 - Indicating Resolver Support of DNSSEC
+     A.8.  RFC 3226 - DNSSEC and IPv6 A6 aware server/resolver message
+            size requirements
+     A.9.  RFC 4472 - Operational Considerations and Issues with IPv6
+            DNS
+     A.10. RFC 5452 - Measures for Making DNS More Resilient against
+            Forged Answers
+     A.11. RFC 5507 - Design Choices When Expanding the DNS
+     A.12. RFC 5625 - DNS Proxy Implementation Guidelines
+     A.13. RFC 5936 - DNS Zone Transfer Protocol (AXFR)
+     A.14. RFC 7534 - AS112 Nameserver Operations
+     A.15. RFC 6762 - Multicast DNS
+     A.16. RFC 6891 - Extension Mechanisms for DNS (EDNS(0))
+     A.17. IAB RFC 6950 - Architectural Considerations on Application
+            Features in the DNS
+     A.18. RFC 7477 - Child-to-Parent Synchronization in DNS
+     A.19. RFC 7720 - DNS Root Name Service Protocol and Deployment
+            Requirements
+     A.20. RFC 7766 - DNS Transport over TCP - Implementation
+            Requirements
+     A.21. RFC 7828 - The edns-tcp-keepalive EDNS(0) Option
+     A.22. RFC 7858 - Specification for DNS over Transport Layer
+            Security (TLS)
+     A.23. RFC 7873 - Domain Name System (DNS) Cookies
+     A.24. RFC 7901 - CHAIN Query Requests in DNS
+     A.25. RFC 8027 - DNSSEC Roadblock Avoidance
+     A.26. RFC 8094 - DNS over Datagram Transport Layer Security
+            (DTLS)
+     A.27. RFC 8162 - Using Secure DNS to Associate Certificates with
+            Domain Names for S/MIME
+     A.28. RFC 8324 - DNS Privacy, Authorization, Special Uses,
+            Encoding, Characters, Matching, and Root Structure: Time for
+            Another Look?
+     A.29. RFC 8467 - Padding Policies for Extension Mechanisms for
+            DNS (EDNS(0))
+     A.30. RFC 8482 - Providing Minimal-Sized Responses to DNS Queries
+            That Have QTYPE=ANY
+     A.31. RFC 8483 - Yeti DNS Testbed
+     A.32. RFC 8484 - DNS Queries over HTTPS (DoH)
+     A.33. RFC 8490 - DNS Stateful Operations
+     A.34. RFC 8501 - Reverse DNS in IPv6 for Internet Service
+            Providers
+     A.35. RFC 8806 - Running a Root Server Local to a Resolver
+     A.36. RFC 8906 - A Common Operational Problem in DNS Servers:
+            Failure to Communicate
+     A.37. RFC 8932 - Recommendations for DNS Privacy Service
+            Operators
+     A.38. RFC 8945 - Secret Key Transaction Authentication for DNS
+            (TSIG)
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   DNS messages are 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.  When DNS over TCP has been
+   restricted, a variety of communication failures and debugging
+   challenges often arise.  As DNS and new naming system features have
+   evolved, TCP as a transport has become increasingly important for the
+   correct and safe operation of an Internet DNS.  Reflecting modern
+   usage, the DNS standards declare that support for TCP is a required
+   part of the DNS implementation specifications [RFC7766].  This
+   document is the equivalent of formal requirements for the operational
+   community, encouraging system administrators, network engineers, and
+   security staff to ensure DNS-over-TCP communications support is on
+   par with DNS-over-UDP communications.  It updates [RFC1123],
+   Section 6.1.3.2 to clarify that all DNS resolvers and recursive
+   servers MUST support and service both TCP and UDP queries and also
+   updates [RFC1536] to remove the misconception that TCP is only useful
+   for zone transfers.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  History of DNS over TCP
+
+   The curious state of disagreement between operational best practices
+   and guidance for DNS transport protocols derives from conflicting
+   messages operators have received from other operators, implementors,
+   and even the IETF.  Sometimes these mixed signals have been explicit;
+   on other occasions, conflicting messages have been implicit.  This
+   section presents an interpretation of the storied and conflicting
+   history that led to this document.  This section is included for
+   informational purposes only.
+
+2.1.  Uneven Transport Usage and Preference
+
+   In the original suite of DNS specifications, [RFC1034] and [RFC1035]
+   clearly specify that DNS messages could be carried in either UDP or
+   TCP, but they also state that there is a preference for UDP as the
+   best transport for queries in the general case.  As stated in
+   [RFC1035]:
+
+   |  While virtual circuits can be used for any DNS activity, datagrams
+   |  are preferred for queries due to their lower overhead and better
+   |  performance.
+
+   Another early, important, and influential document, [RFC1123], marks
+   the preference for a transport protocol more explicitly:
+
+   |  DNS resolvers and recursive servers MUST support UDP, and SHOULD
+   |  support TCP, for sending (non-zone-transfer) queries.
+
+   and it further stipulates that:
+
+   |  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.
+
+   Culminating in [RFC1536], 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.
+
+2.2.  Waiting for Large Messages and Reliability
+
+   In the original specifications, the maximum DNS-over-UDP message size
+   was enshrined at 512 bytes.  However, even while [RFC1123] prefers
+   UDP for non-zone transfer queries, it foresaw that DNS over TCP would
+   become more popular in the future to overcome this limitation:
+
+   |  [...] 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.
+
+   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 [RFC2136], and the second was the set of
+   extensions collectively known as "DNSSEC", whose operational
+   considerations were originally given in [RFC2541] (note that
+   [RFC2541] has been obsoleted by [RFC6781]).  The former suggests that
+
+   |  ...requestors who require an accurate response code must use TCP.
+
+   while the latter warns that
+
+   |  ... larger keys increase the size of the KEY and SIG RRs.  This
+   |  increases the chance of DNS UDP packet overflow and the possible
+   |  necessity for using higher overhead TCP in responses.
+
+   Yet, defying some expectations, DNS over TCP remained little used in
+   real traffic across the Internet in the late 1990s.  Dynamic updates
+   saw little deployment between autonomous networks.  Around the time
+   DNSSEC was first defined, another new feature helped solidify UDP
+   transport dominance for message transactions.
+
+2.3.  EDNS(0)
+
+   In 1999, the IETF published the Extension Mechanisms for DNS
+   (EDNS(0)) in [RFC2671] (which was obsoleted by [RFC6891] in 2013).
+   That 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 EDNS(0)-
+   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 over UDP.  In practice, typical values are a subset of
+   the 512- to 4096-byte range.  EDNS(0) became widely deployed over the
+   next several years, and numerous surveys (see [CASTRO2010] and
+   [NETALYZR]) have shown that many systems support larger UDP MTUs with
+   EDNS(0).
+
+   The natural effect of EDNS(0) 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 lacked
+   EDNS(0) or fell back to TCP when necessary, DNS clients still
+   strongly prefer UDP to TCP.  For example, as of 2014, DNS-over-TCP
+   transactions remained a very small fraction of overall DNS traffic
+   received by root name servers [VERISIGN].
+
+2.4.  Fragmentation and Truncation
+
+   Although EDNS(0) 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.
+
+   For IPv4-connected hosts, the MTU is often an 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, although
+   tunnel encapsulation may reduce that maximum message size in some
+   cases.
+
+   For IPv6, the situation is a little more complicated.  First, IPv6
+   headers are 40 bytes (versus 20 without options in IPv4).  Second,
+   approximately one-third of DNS recursive resolvers use the minimum
+   MTU of 1280 bytes [APNIC].  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 [HUSTON], some
+   35% of IPv6-capable recursive resolvers were unable to receive a
+   fragmented IPv6 packet.  When the originating host receives a signal
+   that fragmentation is required, it is expected to populate its path
+   MTU cache for that destination.  The application will then retry the
+   query after a timeout since the host does not generally retain copies
+   of messages sent over UDP for potential retransmission.
+
+   The practical consequence of all this is that DNS requestors must be
+   prepared to retry queries with different EDNS(0) maximum message size
+   values.  Administrators of [BIND] are likely to be familiar with
+   seeing the following message in their system logs: "success resolving
+   ... after reducing the advertised EDNS(0) UDP packet size to 512
+   octets".
+
+   Often, reducing the EDNS(0) 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 is
+   potentially undesirable from the server's point of view due to the
+   increased resource requirements of TCP.
+
+   Note that a receiver is unable to differentiate between packets lost
+   due to congestion and packets (fragments) intentionally dropped by
+   firewalls or middleboxes.  Over network paths with non-trivial
+   amounts of packet loss, larger, fragmented DNS responses are more
+   likely to never arrive and time out compared to smaller, unfragmented
+   responses.  Clients might be misled into retrying queries with
+   different EDNS(0) UDP packet size values for the wrong reason.
+
+   The issues around fragmentation, truncation, and TCP are driving
+   certain implementation and policy decisions in the DNS.  Notably,
+   Cloudflare implemented a technique that minimizes the number of
+   DNSSEC denial-of-existence records (for its online signing platform)
+   [CLOUDFLARE] and uses an Elliptic Curve Digital Signature Algorithm
+   (ECDSA) such that its signed responses fit easily in 512 bytes.  The
+   Key Signing Key (KSK) Rollover Design Team [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 [ECDSA].
+
+   More recently, renewed security concerns about fragmented DNS
+   messages (see [AVOID_FRAGS] and [FRAG_POISON]) are leading
+   implementors to consider smaller responses and lower default EDNS(0)
+   UDP payload size values for both queriers and responders
+   [FLAGDAY2020].
+
+2.5.  "Only Zone Transfers Use TCP"
+
+   Today, the majority of the DNS community expects, or at least has a
+   desire, to see DNS-over-TCP transactions occur without interference
+   [FLAGDAY2020].  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
+   [CHES94] [DJBDNS].  A popular meme is 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.
+
+   The position on restricting DNS over TCP had some justification given
+   that historical implementations of DNS name servers provided very
+   little in the way of TCP connection management (for example, see
+   Section 6.1.2 of [RFC7766] for more details).  However, modern
+   standards and implementations are nearing parity with the more
+   sophisticated TCP management techniques employed by, for example,
+   HTTP(S) servers and load balancers.
+
+2.6.  Reuse, Pipelining, and Out-of-Order Processing
+
+   The idea that a TCP connection can support multiple transactions goes
+   back as far as [RFC0883], which states: "Multiple messages may be
+   sent over a virtual circuit."  Although [RFC1035], which updates the
+   former, omits this particular detail, it has been generally accepted
+   that a TCP connection can be used for more than one query and
+   response.
+
+   [RFC5966] clarifies that servers are not required to preserve the
+   order of queries and responses over any transport.  [RFC7766], which
+   updates the former, further encourages query pipelining over TCP to
+   achieve performance on par with UDP.  A server that sends out-of-
+   order responses to pipelined queries avoids head-of-line blocking
+   when the response for a later query is ready before the response to
+   an earlier query.
+
+   However, TCP can potentially suffer from a different head-of-line
+   blocking problem due to packet loss.  Since TCP itself enforces
+   ordering, a single lost segment delays delivery of data in any
+   following segments until the lost segment is retransmitted and
+   successfully received.
+
+3.  DNS-over-TCP Requirements
+
+   An average increase in DNS message size (e.g., due to DNSSEC), the
+   continued development of new DNS features (Appendix A), and a denial-
+   of-service mitigation technique (Section 8) all show 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 research that argues connection-oriented DNS transactions may
+   provide security and privacy advantages over UDP transport [TDNS].
+   In fact, the standard for DNS over TLS [RFC7858] is just this sort of
+   specification.  Therefore, this document makes explicit that it is
+   undesirable for network operators to artificially inhibit DNS-over-
+   TCP transport.
+
+   Section 6.1.3.2 of [RFC1123] is updated as follows:
+
+   OLD:
+
+   |  DNS resolvers and recursive servers MUST support UDP, and SHOULD
+   |  support TCP, for sending (non-zone-transfer) queries.
+
+   NEW:
+
+   |  All DNS resolvers and servers MUST support and service both UDP
+   |  and TCP queries.
+
+   Note that:
+
+   *  DNS servers (including forwarders) MUST support and service TCP
+      for receiving queries so that clients can reliably receive
+      responses that are larger than what either side considers too
+      large for UDP.
+
+   *  DNS clients MUST support TCP for sending queries so that they can
+      retry truncated UDP responses as necessary.
+
+   Furthermore, the requirement in Section 6.1.3.2 of [RFC1123] around
+   limiting the resources a server devotes to queries is hereby updated:
+
+   OLD:
+
+   |  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.
+
+   NEW:
+
+   |  A name server MAY limit 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.
+
+   Lastly, Section 1 of [RFC1536] is updated to eliminate the
+   misconception that TCP is only useful for zone transfers:
+
+   OLD:
+
+   |  DNS implements the classic request-response scheme of client-
+   |  server interaction.  UDP is, therefore, the chosen protocol for
+   |  communication though TCP is used for zone transfers.
+
+   NEW:
+
+   |  DNS implements the classic request-response scheme of client-
+   |  server interaction.
+
+   The filtering of DNS over TCP is harmful in the general case.  DNS
+   resolver and server operators MUST support and provide DNS service
+   over both UDP and TCP transports.  Likewise, network operators MUST
+   allow DNS service over both UDP and TCP transports.  It is
+   acknowledged that DNS-over-TCP service can pose operational
+   challenges that are not present when running DNS over UDP alone, and
+   vice versa.  However, 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.
+
+4.  Network and System Considerations
+
+   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.
+
+4.1.  Connection Establishment and Admission
+
+   Resolvers and other DNS clients should be aware that some servers
+   might not be reachable over TCP.  For this reason, clients MAY track
+   and limit the number of TCP connections and connection attempts to a
+   single server.  Reachability problems can be caused by network
+   elements close to the server, close to the client, or anywhere along
+   the path between them.  Mobile clients that cache connection failures
+   MAY do so on a per-network basis or MAY clear such a cache upon
+   change of network.
+
+   Additionally, DNS clients MAY enforce a short timeout on
+   unestablished connections rather than rely on the host operating
+   system's TCP connection timeout, which is often around 60-120 seconds
+   (i.e., due to an initial retransmission timeout of 1 second, the
+   exponential back-off rules of [RFC6298], and a limit of six retries
+   as is the default in Linux).
+
+   The SYN flooding attack is a denial-of-service method affecting hosts
+   that run TCP server processes [RFC4987].  This attack can be very
+   effective if not mitigated.  One of the most effective mitigation
+   techniques is SYN cookies, described in Section 3.6 of [RFC4987],
+   which allows the server to avoid allocating any state until the
+   successful completion of the three-way handshake.
+
+   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 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.  See also [RFC5358].
+
+   The FreeBSD and NetBSD operating systems have an "accept filter"
+   feature ([accept_filter]) 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.  The
+   Linux TCP_DEFER_ACCEPT feature, while more limited in scope, can
+   provide some of the same benefits as the BSD accept filter feature.
+   These features are implemented as low-level socket options and are
+   not activated automatically.  If applications wish to use these
+   features, they need to make specific calls to set the right options,
+   and administrators may also need to configure the applications to
+   appropriately use the features.
+
+   Per [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.
+
+   TCP Fast Open (TFO) [RFC7413] 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
+   either use the same TFO server key on all instances or disable TFO
+   for all members of the cluster.
+
+   DNS clients MAY also enable TFO.  At the time of this writing, it is
+   not implemented or is disabled by default on some operating systems.
+   [WIKIPEDIA_TFO] describes applications and operating systems that
+   support TFO.
+
+4.2.  Connection Management
+
+   Since host memory for TCP state is a finite resource, DNS clients and
+   servers SHOULD 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 trade-off between keeping connections open for
+   potential future use and the need to free up resources for new
+   connections that will arrive.
+
+   Operators of DNS server software SHOULD be aware that operating
+   system and application vendors MAY impose a limit on the total number
+   of established connections.  These limits may be designed to protect
+   against DDoS attacks or performance degradation.  Operators SHOULD
+   understand how to increase these limits if necessary and the
+   consequences of doing so.  Limits imposed by the application SHOULD
+   be lower than limits imposed by the operating system so that the
+   application can apply its own policy to connection management, such
+   as closing the oldest idle connections first.
+
+   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 cannot consume all
+   TCP resources and deny service to other users.  Note, however, that
+   if this limit is enabled, it possibly limits client performance while
+   leaving some TCP resources unutilized.  Operators SHOULD be aware of
+   these trade-offs and ensure this limit, if configured, is set
+   appropriately based on the number and diversity of their users and
+   whether users connect from unique IP addresses or through a shared
+   Network Address Translator (NAT) [RFC3022].
+
+   DNS server software SHOULD provide a configurable timeout for idle
+   TCP connections.  This can be used to free up resources for new
+   connections and to ensure that idle connections are eventually
+   closed.  At the same time, it possibly limits client performance
+   while leaving some TCP resources unutilized.  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 EDNS(0) option [RFC7828].
+
+   DNS server software MAY provide a configurable limit on the number of
+   transactions per TCP connection.  This can help protect against
+   unfair connection use (e.g., not releasing connection slots to other
+   clients) and network evasion attacks.
+
+   Similarly, DNS server software MAY provide a configurable limit on
+   the total duration of a TCP connection.  This can help protect
+   against unfair connection use, slow read attacks, and network evasion
+   attacks.
+
+   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.
+
+4.3.  Connection Termination
+
+   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.
+   It is generally preferable for clients to initiate the close of a TCP
+   connection so that busy servers do not accumulate many sockets in the
+   TIME_WAIT state, which can cause performance problems or even denial
+   of service.  The edns-tcp-keepalive EDNS(0) option [RFC7828] can be
+   used to encourage clients to close connections.
+
+   On systems where large numbers of sockets in TIME_WAIT are observed
+   (as either a client or a server) and are affecting an application's
+   performance, it may be tempting to tune local TCP parameters.  For
+   example, the Linux kernel has a "sysctl" parameter named
+   net.ipv4.tcp_tw_reuse, which allows connections in the TIME_WAIT
+   state to be reused in specific circumstances.  Note, however, that
+   this affects only outgoing (client) connections and has no impact on
+   servers.  In most cases, it is NOT RECOMMENDED to change parameters
+   related to the TIME_WAIT state.  It should only be done by those with
+   detailed knowledge of both TCP and the affected application.
+
+4.4.  DNS over TLS
+
+   DNS messages may be sent over TLS to provide privacy between stubs
+   and recursive resolvers.  [RFC7858] is a Standards Track document
+   describing how this works.  Although DNS over TLS utilizes TCP port
+   853 instead of port 53, this document applies equally well to DNS
+   over TLS.  Note, however, that DNS over TLS is only defined between
+   stubs and recursives at the time of this writing.
+
+   The use of TLS places even stronger operational burdens on DNS
+   clients and servers.  Cryptographic functions for authentication and
+   encryption require additional processing.  Unoptimized connection
+   setup with TLS 1.3 [RFC8446] takes one additional round trip compared
+   to TCP.  Connection setup times can be reduced with TCP Fast Open and
+   TLS False Start [RFC7918] for TLS 1.2.  TLS 1.3 session resumption
+   does not reduce round-trip latency because no application profile for
+   use of TLS 0-RTT data with DNS has been published at the time of this
+   writing.  However, TLS session resumption can reduce the number of
+   cryptographic operations, and in TLS 1.2, session resumption does
+   reduce the number of additional round trips from two to one.
+
+4.5.  Defaults and Recommended Limits
+
+   A survey of features and defaults was conducted for popular open-
+   source DNS server implementations at the time of writing.  This
+   section documents those defaults and makes recommendations for
+   configurable limits that can be used in the absence of any other
+   information.  Any recommended values in this document are only
+   intended as a starting point for administrators that are unsure of
+   what sorts of limits might be reasonable.  Operators SHOULD use
+   application-specific monitoring, system logs, and system monitoring
+   tools to gauge whether their service is operating within or exceeding
+   these limits and adjust accordingly.
+
+   Most open-source DNS server implementations provide a configurable
+   limit on the total number of established connections.  Default values
+   range from 20 to 150.  In most cases, where the majority of queries
+   take place over UDP, 150 is a reasonable limit.  For services or
+   environments where most queries take place over TCP or TLS, 5000 is a
+   more appropriate limit.
+
+   Only some open-source implementations provide a way to limit the
+   number of connections per source IP address or subnet, but the
+   default is to have no limit.  For environments or situations where it
+   may be necessary to enable this limit, 25 connections per source IP
+   address is a reasonable starting point.  The limit should be
+   increased when aggregated by subnet or for services where most
+   queries take place over TCP or TLS.
+
+   Most open-source implementations provide a configurable idle timeout
+   on connections.  Default values range from 2 to 30 seconds.  In most
+   cases, 10 seconds is a reasonable default for this limit.  Longer
+   timeouts improve connection reuse, but busy servers may need to use a
+   lower limit.
+
+   Only some open-source implementations provide a way to limit the
+   number of transactions per connection, but the default is to have no
+   limit.  This document does not offer advice on particular values for
+   such a limit.
+
+   Only some open-source implementations provide a way to limit the
+   duration of connection, but the default is to have no limit.  This
+   document does not offer advice on particular values for such a limit.
+
+5.  DNS-over-TCP Filtering Risks
+
+   Networks that filter DNS over TCP risk losing access to significant
+   or important pieces of the DNS namespace.  For a variety of reasons,
+   a DNS answer may require a DNS-over-TCP query.  This may include
+   large message sizes, lack of EDNS(0) support, or DDoS mitigation
+   techniques (including Response Rate Limiting [RRL]); additionally,
+   perhaps some future capability that is as yet unforeseen will also
+   demand TCP transport.
+
+   For example, [RFC7901] describes a latency-avoiding technique that
+   sends extra data in DNS responses.  This makes responses larger and
+   potentially increases the effectiveness of DDoS reflection attacks.
+   The specification mandates the use of TCP or DNS cookies [RFC7873].
+
+   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 at the time of this
+   writing when networks filter DNS over TCP.
+
+5.1.  Truncation, Retries, and Timeouts
+
+   Networks that filter DNS over TCP may inadvertently cause problems
+   for third-party resolvers as experienced by [TOYAMA].  For example, a
+   resolver receives queries for a moderately popular domain.  The
+   resolver forwards the queries to the domain's authoritative name
+   servers, but those servers respond with the TC bit set.  The resolver
+   retries over TCP, but the authoritative server blocks DNS over TCP.
+   The pending connections consume resources on the resolver until they
+   time out.  If the number and frequency of these truncated-and-then-
+   blocked queries are sufficiently high, the resolver wastes valuable
+   resources on queries that can never be answered.  This condition is
+   generally not easily or completely mitigated by the affected DNS
+   resolver operator.
+
+5.2.  DNS Root Zone KSK Rollover
+
+   The plans for deploying DNSSEC KSK for the root zone highlighted a
+   potential problem in retrieving the root zone key set [LEWIS].
+   During some phases of the KSK rollover process, root zone DNSKEY
+   responses were larger than 1280 bytes, the IPv6 minimum MTU for links
+   carrying IPv6 traffic [RFC8200].  There was some concern that any DNS
+   server unable to receive large DNS messages over UDP, or any DNS
+   message over TCP, would experience disruption while performing DNSSEC
+   validation [KSK_ROLLOVER_ARCHIVES].
+
+   However, during the year-long postponement of the KSK rollover, there
+   were no reported problems that could be attributed to the 1414 octet
+   DNSKEY response when both the old and new keys were published in the
+   zone.  Additionally, there were no reported problems during the two-
+   month period when the old key was published as revoked and the DNSKEY
+   response was 1425 octets in size [ROLL_YOUR_ROOT].
+
+6.  Logging and Monitoring
+
+   Developers of applications that log or monitor DNS SHOULD NOT ignore
+   TCP due to the perception that it is rarely used or is hard to
+   process.  Operators SHOULD ensure that their monitoring and logging
+   applications properly capture DNS messages over TCP.  Otherwise,
+   attacks, exfiltration attempts, and normal traffic may go undetected.
+
+   DNS messages over TCP are in no way guaranteed to arrive in single
+   segments.  In fact, a clever attacker might attempt to hide certain
+   messages by forcing them over very small TCP segments.  Applications
+   that capture network packets (e.g., with libpcap [libpcap]) SHOULD
+   implement and perform full TCP stream reassembly and analyze the
+   reassembled stream instead of the individual packets.  Otherwise,
+   they are vulnerable to network evasion attacks [phrack].
+   Furthermore, such applications need to protect themselves from
+   resource exhaustion attacks by limiting the amount of memory
+   allocated to tracking unacknowledged connection state data.  dnscap
+   [dnscap] is an open-source example of a DNS logging program that
+   implements TCP stream reassembly.
+
+   Developers SHOULD also keep in mind connection reuse, query
+   pipelining, and out-of-order responses when building and testing DNS
+   monitoring applications.
+
+   As an alternative to packet capture, some DNS server software
+   supports dnstap [dnstap] as an integrated monitoring protocol
+   intended to facilitate wide-scale DNS monitoring.
+
+7.  IANA Considerations
+
+   This document has no IANA actions.
+
+8.  Security Considerations
+
+   This document, providing operational requirements, is the companion
+   to the implementation requirements of DNS over TCP provided in
+   [RFC7766].  The security considerations from [RFC7766] still apply.
+
+   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
+   [RRL].  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.  In fact,
+   [DAI21] details a class of IP fragmentation attacks on DNS
+   transactions if the IP Identifier field (16 bits in IPv4 and 32 bits
+   in IPv6) can be predicted and a system is coerced to fragment rather
+   than retransmit messages.  While many operators have provided DNS-
+   over-TCP service for many years without duress, past experience is no
+   guarantee of future success.
+
+   DNS over TCP is similar to many other Internet TCP services.  TCP
+   threats and many mitigation strategies have been well documented in a
+   series of documents such as [RFC4953], [RFC4987], [RFC5927], and
+   [RFC5961].
+
+   As mentioned in Section 6, applications that implement TCP stream
+   reassembly need to limit the amount of memory allocated to connection
+   tracking.  A failure to do so could lead to a total failure of the
+   logging or monitoring application.  Imposition of resource limits
+   creates a trade-off between allowing some stream reassembly to
+   continue and allowing some evasion attacks to succeed.
+
+   This document recommends that DNS servers enable TFO when possible.
+   [RFC7413] recommends that a pool of servers behind a load balancer
+   with a shared server IP address also share the key used to generate
+   Fast Open cookies to prevent inordinate fallback to the three-way
+   handshake (3WHS).  This guidance remains accurate but comes with a
+   caveat: compromise of one server would reveal this group-shared key
+   and allow for attacks involving the other servers in the pool by
+   forging invalid Fast Open cookies.
+
+9.  Privacy Considerations
+
+   Since DNS over both UDP and TCP uses the same underlying message
+   format, the use of one transport instead of the other does not change
+   the privacy characteristics of the message content (i.e., the name
+   being queried).  A number of protocols have recently been developed
+   to provide DNS privacy, including DNS over TLS [RFC7858], DNS over
+   DTLS [RFC8094], DNS over HTTPS [RFC8484], with even more on the way.
+
+   Because TCP is somewhat more complex than UDP, some characteristics
+   of a TCP conversation may enable DNS client fingerprinting and
+   tracking that is not possible with UDP.  For example, the choice of
+   initial sequence numbers, window size, and options might be able to
+   identify a particular TCP implementation or even individual hosts
+   behind shared resources such as NATs.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+              November 1987, <https://www.rfc-editor.org/info/rfc1035>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
+              <https://www.rfc-editor.org/info/rfc2181>.
+
+   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
+              for DNS (EDNS(0))", STD 75, RFC 6891,
+              DOI 10.17487/RFC6891, April 2013,
+              <https://www.rfc-editor.org/info/rfc6891>.
+
+   [RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
+              D. Wessels, "DNS Transport over TCP - Implementation
+              Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
+              <https://www.rfc-editor.org/info/rfc7766>.
+
+   [RFC7828]  Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
+              edns-tcp-keepalive EDNS0 Option", RFC 7828,
+              DOI 10.17487/RFC7828, April 2016,
+              <https://www.rfc-editor.org/info/rfc7828>.
+
+   [RFC7873]  Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
+              Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
+              <https://www.rfc-editor.org/info/rfc7873>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+10.2.  Informative References
+
+   [accept_filter]
+              FreeBSD, "FreeBSD accept_filter(9)", June 2000,
+              <https://www.freebsd.org/cgi/man.cgi?query=accept_filter>.
+
+   [APNIC]    Huston, G., "DNS XL", October 2020,
+              <https://labs.apnic.net/?p=1380>.
+
+   [AVOID_FRAGS]
+              Fujiwara, K. and P. Vixie, "Fragmentation Avoidance in
+              DNS", Work in Progress, Internet-Draft, draft-ietf-dnsop-
+              avoid-fragmentation-06, 23 December 2021,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
+              avoid-fragmentation-06>.
+
+   [BIND]     Internet Systems Consortium, "BIND 9",
+              <https://www.isc.org/bind/>.
+
+   [CASTRO2010]
+              Castro, S., Zhang, M., John, W., Wessels, D., and K.
+              claffy, "Understanding and Preparing for DNS Evolution",
+              DOI 10.1007/978-3-642-12365-8_1, April 2010,
+              <https://doi.org/10.1007/978-3-642-12365-8_1>.
+
+   [CHES94]   Cheswick, W. and S. Bellovin, "Firewalls and Internet
+              Security: Repelling the Wily Hacker", First Edition, 1994.
+
+   [CLOUDFLARE]
+              Grant, D., "Economical With The Truth: Making DNSSEC
+              Answers Cheap", June 2016,
+              <https://blog.cloudflare.com/black-lies/>.
+
+   [DAI21]    Dai, T., Shulman, H., and M. Waidner, "DNS-over-TCP
+              Considered Vulnerable", DOI 10.1145/3472305.3472884, July
+              2021, <https://doi.org/10.1145/3472305.3472884>.
+
+   [DESIGNTEAM]
+              ICANN, "Root Zone KSK Rollover Plan", March 2016,
+              <https://www.iana.org/reports/2016/root-ksk-rollover-
+              design-20160307.pdf>.
+
+   [DJBDNS]   Bernstein, D., "When are TCP queries sent?", November
+              2002, <https://cr.yp.to/djbdns/tcp.html#why>.
+
+   [dnscap]   DNS-OARC, "DNSCAP", February 2014,
+              <https://www.dns-oarc.net/tools/dnscap>.
+
+   [dnstap]   "dnstap", <https://dnstap.info>.
+
+   [ECDSA]    van Rijswijk-Deij, R., Sperotto, A., and A. Pras, "Making
+              the Case for Elliptic Curves in DNSSEC",
+              DOI 10.1145/2831347.2831350, October 2015,
+              <https://dl.acm.org/doi/10.1145/2831347.2831350>.
+
+   [FLAGDAY2020]
+              DNS Software and Service Providers, "DNS Flag Day 2020",
+              October 2020, <https://dnsflagday.net/2020/>.
+
+   [FRAG_POISON]
+              Herzberg, A. and H. Shulman, "Fragmentation Considered
+              Poisonous", May 2012,
+              <https://arxiv.org/pdf/1205.4011.pdf>.
+
+   [HUSTON]   Huston, G., "Dealing with IPv6 fragmentation in the DNS",
+              August 2017, <https://blog.apnic.net/2017/08/22/dealing-
+              ipv6-fragmentation-dns/>.
+
+   [KSK_ROLLOVER_ARCHIVES]
+              ICANN, "KSK Rollover List Archives", January 2019,
+              <https://mm.icann.org/pipermail/ksk-rollover/2019-January/
+              date.html>.
+
+   [LEWIS]    Lewis, E., "2017 DNSSEC KSK Rollover", RIPE 74, May 2017,
+              <https://ripe74.ripe.net/presentations/25-RIPE74-lewis-
+              submission.pdf>.
+
+   [libpcap]  The Tcpdump Group, "Tcpdump and Libpcap",
+              <https://www.tcpdump.org>.
+
+   [NETALYZR] Kreibich, C., Weaver, N., Nechaev, B., and V. Paxson,
+              "Netalyzr: Illuminating The Edge Network",
+              DOI 10.1145/1879141.1879173, November 2010,
+              <https://doi.org/10.1145/1879141.1879173>.
+
+   [phrack]   horizon, "Defeating Sniffers and Intrusion Detection
+              Systems", Phrack Magazine, December 1998,
+              <http://phrack.org/issues/54/10.html>.
+
+   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              DOI 10.17487/RFC0768, August 1980,
+              <https://www.rfc-editor.org/info/rfc768>.
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, DOI 10.17487/RFC0793, September 1981,
+              <https://www.rfc-editor.org/info/rfc793>.
+
+   [RFC0883]  Mockapetris, P., "Domain names: Implementation
+              specification", RFC 883, DOI 10.17487/RFC0883, November
+              1983, <https://www.rfc-editor.org/info/rfc883>.
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
+              <https://www.rfc-editor.org/info/rfc1034>.
+
+   [RFC1123]  Braden, R., Ed., "Requirements for Internet Hosts -
+              Application and Support", STD 3, RFC 1123,
+              DOI 10.17487/RFC1123, October 1989,
+              <https://www.rfc-editor.org/info/rfc1123>.
+
+   [RFC1536]  Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
+              Miller, "Common DNS Implementation Errors and Suggested
+              Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993,
+              <https://www.rfc-editor.org/info/rfc1536>.
+
+   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+              DOI 10.17487/RFC1995, August 1996,
+              <https://www.rfc-editor.org/info/rfc1995>.
+
+   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
+              Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
+              August 1996, <https://www.rfc-editor.org/info/rfc1996>.
+
+   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, DOI 10.17487/RFC2136, April 1997,
+              <https://www.rfc-editor.org/info/rfc2136>.
+
+   [RFC2541]  Eastlake 3rd, D., "DNS Security Operational
+              Considerations", RFC 2541, DOI 10.17487/RFC2541, March
+              1999, <https://www.rfc-editor.org/info/rfc2541>.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, DOI 10.17487/RFC2671, August 1999,
+              <https://www.rfc-editor.org/info/rfc2671>.
+
+   [RFC2694]  Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A.
+              Heffernan, "DNS extensions to Network Address Translators
+              (DNS_ALG)", RFC 2694, DOI 10.17487/RFC2694, September
+              1999, <https://www.rfc-editor.org/info/rfc2694>.
+
+   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
+              Address Translator (Traditional NAT)", RFC 3022,
+              DOI 10.17487/RFC3022, January 2001,
+              <https://www.rfc-editor.org/info/rfc3022>.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC",
+              RFC 3225, DOI 10.17487/RFC3225, December 2001,
+              <https://www.rfc-editor.org/info/rfc3225>.
+
+   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
+              message size requirements", RFC 3226,
+              DOI 10.17487/RFC3226, December 2001,
+              <https://www.rfc-editor.org/info/rfc3226>.
+
+   [RFC4472]  Durand, A., Ihren, J., and P. Savola, "Operational
+              Considerations and Issues with IPv6 DNS", RFC 4472,
+              DOI 10.17487/RFC4472, April 2006,
+              <https://www.rfc-editor.org/info/rfc4472>.
+
+   [RFC4953]  Touch, J., "Defending TCP Against Spoofing Attacks",
+              RFC 4953, DOI 10.17487/RFC4953, July 2007,
+              <https://www.rfc-editor.org/info/rfc4953>.
+
+   [RFC4987]  Eddy, W., "TCP SYN Flooding Attacks and Common
+              Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
+              <https://www.rfc-editor.org/info/rfc4987>.
+
+   [RFC5358]  Damas, J. and F. Neves, "Preventing Use of Recursive
+              Nameservers in Reflector Attacks", BCP 140, RFC 5358,
+              DOI 10.17487/RFC5358, October 2008,
+              <https://www.rfc-editor.org/info/rfc5358>.
+
+   [RFC5452]  Hubert, A. and R. van Mook, "Measures for Making DNS More
+              Resilient against Forged Answers", RFC 5452,
+              DOI 10.17487/RFC5452, January 2009,
+              <https://www.rfc-editor.org/info/rfc5452>.
+
+   [RFC5507]  IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch,
+              Ed., "Design Choices When Expanding the DNS", RFC 5507,
+              DOI 10.17487/RFC5507, April 2009,
+              <https://www.rfc-editor.org/info/rfc5507>.
+
+   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",
+              BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
+              <https://www.rfc-editor.org/info/rfc5625>.
+
+   [RFC5927]  Gont, F., "ICMP Attacks against TCP", RFC 5927,
+              DOI 10.17487/RFC5927, July 2010,
+              <https://www.rfc-editor.org/info/rfc5927>.
+
+   [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
+              (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
+              <https://www.rfc-editor.org/info/rfc5936>.
+
+   [RFC5961]  Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
+              Robustness to Blind In-Window Attacks", RFC 5961,
+              DOI 10.17487/RFC5961, August 2010,
+              <https://www.rfc-editor.org/info/rfc5961>.
+
+   [RFC5966]  Bellis, R., "DNS Transport over TCP - Implementation
+              Requirements", RFC 5966, DOI 10.17487/RFC5966, August
+              2010, <https://www.rfc-editor.org/info/rfc5966>.
+
+   [RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,
+              "Computing TCP's Retransmission Timer", RFC 6298,
+              DOI 10.17487/RFC6298, June 2011,
+              <https://www.rfc-editor.org/info/rfc6298>.
+
+   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
+              DOI 10.17487/RFC6762, February 2013,
+              <https://www.rfc-editor.org/info/rfc6762>.
+
+   [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
+              Operational Practices, Version 2", RFC 6781,
+              DOI 10.17487/RFC6781, December 2012,
+              <https://www.rfc-editor.org/info/rfc6781>.
+
+   [RFC6950]  Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
+              "Architectural Considerations on Application Features in
+              the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013,
+              <https://www.rfc-editor.org/info/rfc6950>.
+
+   [RFC7413]  Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
+              Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
+              <https://www.rfc-editor.org/info/rfc7413>.
+
+   [RFC7477]  Hardaker, W., "Child-to-Parent Synchronization in DNS",
+              RFC 7477, DOI 10.17487/RFC7477, March 2015,
+              <https://www.rfc-editor.org/info/rfc7477>.
+
+   [RFC7534]  Abley, J. and W. Sotomayor, "AS112 Nameserver Operations",
+              RFC 7534, DOI 10.17487/RFC7534, May 2015,
+              <https://www.rfc-editor.org/info/rfc7534>.
+
+   [RFC7720]  Blanchet, M. and L-J. Liman, "DNS Root Name Service
+              Protocol and Deployment Requirements", BCP 40, RFC 7720,
+              DOI 10.17487/RFC7720, December 2015,
+              <https://www.rfc-editor.org/info/rfc7720>.
+
+   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
+              and P. Hoffman, "Specification for DNS over Transport
+              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
+              2016, <https://www.rfc-editor.org/info/rfc7858>.
+
+   [RFC7901]  Wouters, P., "CHAIN Query Requests in DNS", RFC 7901,
+              DOI 10.17487/RFC7901, June 2016,
+              <https://www.rfc-editor.org/info/rfc7901>.
+
+   [RFC7918]  Langley, A., Modadugu, N., and B. Moeller, "Transport
+              Layer Security (TLS) False Start", RFC 7918,
+              DOI 10.17487/RFC7918, August 2016,
+              <https://www.rfc-editor.org/info/rfc7918>.
+
+   [RFC8027]  Hardaker, W., Gudmundsson, O., and S. Krishnaswamy,
+              "DNSSEC Roadblock Avoidance", BCP 207, RFC 8027,
+              DOI 10.17487/RFC8027, November 2016,
+              <https://www.rfc-editor.org/info/rfc8027>.
+
+   [RFC8094]  Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
+              Transport Layer Security (DTLS)", RFC 8094,
+              DOI 10.17487/RFC8094, February 2017,
+              <https://www.rfc-editor.org/info/rfc8094>.
+
+   [RFC8162]  Hoffman, P. and J. Schlyter, "Using Secure DNS to
+              Associate Certificates with Domain Names for S/MIME",
+              RFC 8162, DOI 10.17487/RFC8162, May 2017,
+              <https://www.rfc-editor.org/info/rfc8162>.
+
+   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", STD 86, RFC 8200,
+              DOI 10.17487/RFC8200, July 2017,
+              <https://www.rfc-editor.org/info/rfc8200>.
+
+   [RFC8324]  Klensin, J., "DNS Privacy, Authorization, Special Uses,
+              Encoding, Characters, Matching, and Root Structure: Time
+              for Another Look?", RFC 8324, DOI 10.17487/RFC8324,
+              February 2018, <https://www.rfc-editor.org/info/rfc8324>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+   [RFC8467]  Mayrhofer, A., "Padding Policies for Extension Mechanisms
+              for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
+              October 2018, <https://www.rfc-editor.org/info/rfc8467>.
+
+   [RFC8482]  Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt,
+              "Providing Minimal-Sized Responses to DNS Queries That
+              Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January
+              2019, <https://www.rfc-editor.org/info/rfc8482>.
+
+   [RFC8483]  Song, L., Ed., Liu, D., Vixie, P., Kato, A., and S. Kerr,
+              "Yeti DNS Testbed", RFC 8483, DOI 10.17487/RFC8483,
+              October 2018, <https://www.rfc-editor.org/info/rfc8483>.
+
+   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
+              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
+              <https://www.rfc-editor.org/info/rfc8484>.
+
+   [RFC8490]  Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
+              Lemon, T., and T. Pusateri, "DNS Stateful Operations",
+              RFC 8490, DOI 10.17487/RFC8490, March 2019,
+              <https://www.rfc-editor.org/info/rfc8490>.
+
+   [RFC8501]  Howard, L., "Reverse DNS in IPv6 for Internet Service
+              Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018,
+              <https://www.rfc-editor.org/info/rfc8501>.
+
+   [RFC8806]  Kumari, W. and P. Hoffman, "Running a Root Server Local to
+              a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
+              <https://www.rfc-editor.org/info/rfc8806>.
+
+   [RFC8906]  Andrews, M. and R. Bellis, "A Common Operational Problem
+              in DNS Servers: Failure to Communicate", BCP 231,
+              RFC 8906, DOI 10.17487/RFC8906, September 2020,
+              <https://www.rfc-editor.org/info/rfc8906>.
+
+   [RFC8932]  Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and
+              A. Mankin, "Recommendations for DNS Privacy Service
+              Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932,
+              October 2020, <https://www.rfc-editor.org/info/rfc8932>.
+
+   [RFC8945]  Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
+              Gudmundsson, O., and B. Wellington, "Secret Key
+              Transaction Authentication for DNS (TSIG)", STD 93,
+              RFC 8945, DOI 10.17487/RFC8945, November 2020,
+              <https://www.rfc-editor.org/info/rfc8945>.
+
+   [ROLL_YOUR_ROOT]
+              Müller, M., Thomas, M., Wessels, D., Hardaker, W., Chung,
+              T., Toorop, W., and R. van Rijswijk-Deij, "Roll, Roll,
+              Roll Your Root: A Comprehensive Analysis of the First Ever
+              DNSSEC Root KSK Rollover", DOI 10.1145/3355369.3355570,
+              October 2019,
+              <https://dl.acm.org/doi/10.1145/3355369.3355570>.
+
+   [RRL]      Vixie, P. and V. Schryver, "DNS Response Rate Limiting
+              (DNS RRL)", ISC-TN-2012-1-Draft1, April 2012.
+
+   [TDNS]     Zhu, L., Heidemann, J., Wessels, D., Mankin, A., and N.
+              Somaiya, "Connection-Oriented DNS to Improve Privacy and
+              Security", DOI 10.1109/SP.2015.18, May 2015,
+              <https://doi.org/10.1109/SP.2015.18>.
+
+   [TOYAMA]   Toyama, K., Ishibashi, K., Toyono, T., Ishino, M.,
+              Yoshimura, C., and K. Fujiwara, "DNS Anomalies and Their
+              Impacts on DNS Cache Servers", NANOG 32, October 2004.
+
+   [VERISIGN] Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in
+              Root Server DITL Data", DNS-OARC 2014 Fall Workshop,
+              October 2014.
+
+   [WIKIPEDIA_TFO]
+              Wikipedia, "TCP Fast Open", February 2022,
+              <https://en.wikipedia.org/w/
+              index.php?title=TCP_Fast_Open&oldid=1071397204>.
+
+Appendix A.  RFCs Related to DNS Transport over TCP
+
+   This section enumerates all known RFCs with a status of Internet
+   Standard, Proposed Standard, Informational, Best Current Practice, or
+   Experimental that either implicitly or explicitly make assumptions or
+   statements about the use of TCP as a transport for the DNS germane to
+   this document.
+
+A.1.  RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
+
+   The Internet Standard [RFC1035] is the base DNS specification that
+   explicitly defines support for DNS over TCP.
+
+A.2.  RFC 1536 - Common DNS Implementation Errors and Suggested Fixes
+
+   The Informational document [RFC1536] states that UDP is "the chosen
+   protocol for communication though TCP is used for zone transfers."
+   That statement should now be considered in its historical context and
+   is no longer a proper reflection of modern expectations.
+
+A.3.  RFC 1995 - Incremental Zone Transfer in DNS
+
+   The Proposed Standard [RFC1995] documents the use of TCP as the
+   fallback transport when Incremental Zone Transfer (IXFR) responses do
+   not fit into a single UDP response.  As with Authoritative Transfer
+   (AXFR), IXFR messages are typically delivered over TCP by default in
+   practice.
+
+A.4.  RFC 1996 - A Mechanism for Prompt Notification of Zone Changes
+      (DNS NOTIFY)
+
+   The Proposed Standard [RFC1996] suggests that a primary server may
+   decide to issue NOTIFY messages over TCP.  In practice, NOTIFY
+   messages are generally sent over UDP, but this specification leaves
+   open the possibility that the choice of transport protocol is up to
+   the primary server; therefore, a secondary server ought to be able to
+   operate over both UDP and TCP.
+
+A.5.  RFC 2181 - Clarifications to the DNS Specification
+
+   The Proposed Standard [RFC2181] includes clarifying text on how a
+   client should react to the TC bit set on responses.  It is advised
+   that the response be discarded and the query resent using TCP.
+
+A.6.  RFC 2694 - DNS extensions to Network Address Translators (DNS_ALG)
+
+   The Informational document [RFC2694] enumerates considerations for
+   NAT devices to properly handle DNS traffic.  This document is
+   noteworthy in its suggestion that "[t]ypically, TCP is used for AXFR
+   requests," as further evidence that helps explain why DNS over TCP
+   may have often been treated very differently than DNS over UDP in
+   operational networks.
+
+A.7.  RFC 3225 - Indicating Resolver Support of DNSSEC
+
+   The Proposed Standard [RFC3225] makes statements indicating that DNS
+   over TCP is "detrimental" as a result of increased traffic, latency,
+   and server load.  This document is a companion to the next document
+   in the RFC Series that describes the requirement for EDNS(0) support
+   for DNSSEC.
+
+A.8.  RFC 3226 - DNSSEC and IPv6 A6 aware server/resolver message size
+      requirements
+
+   Although updated by later DNSSEC RFCs, the Proposed Standard
+   [RFC3226] strongly argues in favor of UDP messages instead of TCP,
+   largely for performance reasons.  The document declares EDNS(0) a
+   requirement for DNSSEC servers and advocates that packet
+   fragmentation may be preferable to TCP in certain situations.
+
+A.9.  RFC 4472 - Operational Considerations and Issues with IPv6 DNS
+
+   The Informational document [RFC4472] notes that IPv6 data may
+   increase DNS responses beyond what would fit in a UDP message.  What
+   is particularly noteworthy, but perhaps less common today than when
+   this document was written, is that it refers to implementations that
+   truncate data without setting the TC bit to encourage the client to
+   resend the query using TCP.
+
+A.10.  RFC 5452 - Measures for Making DNS More Resilient against Forged
+       Answers
+
+   The Proposed Standard [RFC5452] arose as public DNS systems began to
+   experience widespread abuse from spoofed queries, resulting in
+   amplification and reflection attacks against unwitting victims.  One
+   of the leading justifications for supporting DNS over TCP to thwart
+   these attacks is briefly described in Section 9.3 of [RFC5452]
+   ("Spoof Detection and Countermeasure").
+
+A.11.  RFC 5507 - Design Choices When Expanding the DNS
+
+   The Informational document [RFC5507] was largely an attempt to
+   dissuade new DNS data types from overloading the TXT resource record
+   type.  In so doing, it summarizes the conventional wisdom of DNS
+   design and implementation practices.  The authors suggest TCP
+   overhead and stateful properties pose challenges compared to UDP and
+   imply that UDP is generally preferred for performance and robustness.
+
+A.12.  RFC 5625 - DNS Proxy Implementation Guidelines
+
+   The Best Current Practice document [RFC5625] provides DNS proxy
+   implementation guidance including the mandate that a proxy "MUST
+   [...] be prepared to receive and forward queries over TCP" even
+   though it suggests that, historically, TCP transport has not been
+   strictly mandatory in stub resolvers or recursive servers.
+
+A.13.  RFC 5936 - DNS Zone Transfer Protocol (AXFR)
+
+   The Proposed Standard [RFC5936] 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.
+
+A.14.  RFC 7534 - AS112 Nameserver Operations
+
+   The Informational document [RFC7534] enumerates 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.
+
+A.15.  RFC 6762 - Multicast DNS
+
+   In the Proposed Standard [RFC6762], 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 TC bit set is
+   received, "[...] the querier SHOULD reissue its query using TCP in
+   order to receive the larger response."
+
+A.16.  RFC 6891 - Extension Mechanisms for DNS (EDNS(0))
+
+   The Internet Standard [RFC6891] helped slow the use of and need for
+   DNS-over-TCP messages.  This document highlights concerns over server
+   load and scalability in widespread use of DNS over TCP.
+
+A.17.  IAB RFC 6950 - Architectural Considerations on Application
+       Features in the DNS
+
+   The Informational document [RFC6950] draws attention to large data in
+   the DNS.  TCP is referenced in the context as a common fallback
+   mechanism and counter to some spoofing attacks.
+
+A.18.  RFC 7477 - Child-to-Parent Synchronization in DNS
+
+   The Proposed Standard [RFC7477] specifies an RRType and a 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.
+
+A.19.  RFC 7720 - DNS Root Name Service Protocol and Deployment
+       Requirements
+
+   The Best Current Practice document [RFC7720] declares that root name
+   service "MUST support UDP [RFC0768] and TCP [RFC0793] transport of
+   DNS queries and responses."
+
+A.20.  RFC 7766 - DNS Transport over TCP - Implementation Requirements
+
+   The Proposed Standard [RFC7766] instructs DNS implementors to provide
+   support for carrying DNS-over-TCP messages in their software and
+   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
+   but makes no recommendations to operators, which we seek to address
+   here.
+
+A.21.  RFC 7828 - The edns-tcp-keepalive EDNS(0) Option
+
+   The Proposed Standard [RFC7828] defines an EDNS(0) 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.
+
+A.22.  RFC 7858 - Specification for DNS over Transport Layer Security
+       (TLS)
+
+   The Proposed Standard [RFC7858] defines a method for putting DNS
+   messages into a TCP-based encrypted channel using TLS.  This
+   specification is noteworthy for explicitly targeting the stub-to-
+   recursive traffic but does not preclude its application from
+   recursive-to-authoritative traffic.
+
+A.23.  RFC 7873 - Domain Name System (DNS) Cookies
+
+   The Proposed Standard [RFC7873] describes an EDNS(0) option to
+   provide additional protection against query and answer forgery.  This
+   specification mentions DNS over TCP as an alternative 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.
+
+A.24.  RFC 7901 - CHAIN Query Requests in DNS
+
+   The Experimental specification [RFC7901] describes an EDNS(0) 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 transport
+   mechanism verified by a source IP address such as EDNS-COOKIE
+   [RFC7873].
+
+A.25.  RFC 8027 - DNSSEC Roadblock Avoidance
+
+   The Best Current Practice document [RFC8027] 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", the scope of the document is limited to
+   detection and mitigation techniques to avoid so-called DNSSEC
+   roadblocks.
+
+A.26.  RFC 8094 - DNS over Datagram Transport Layer Security (DTLS)
+
+   The Experimental specification [RFC8094] 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.
+
+A.27.  RFC 8162 - Using Secure DNS to Associate Certificates with Domain
+       Names for S/MIME
+
+   The Experimental specification [RFC8162] 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."
+
+A.28.  RFC 8324 - DNS Privacy, Authorization, Special Uses, Encoding,
+       Characters, Matching, and Root Structure: Time for Another Look?
+
+   The Informational document [RFC8324] briefly discusses the common
+   role and challenges of DNS over TCP throughout the history of DNS.
+
+A.29.  RFC 8467 - Padding Policies for Extension Mechanisms for DNS
+       (EDNS(0))
+
+   The Experimental document [RFC8467] reminds implementors 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.
+
+A.30.  RFC 8482 - Providing Minimal-Sized Responses to DNS Queries That
+       Have QTYPE=ANY
+
+   The Proposed Standard [RFC8482] describes alternative ways that DNS
+   servers can respond to queries of type ANY, which are sometimes used
+   to provide amplification in DDoS attacks.  The specification notes
+   that responders may behave differently, depending on the transport.
+   For example, minimal-sized responses may be used over UDP transport,
+   while full responses may be given over TCP.
+
+A.31.  RFC 8483 - Yeti DNS Testbed
+
+   The Informational document [RFC8483] 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.
+
+A.32.  RFC 8484 - DNS Queries over HTTPS (DoH)
+
+   The Proposed Standard [RFC8484] 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 technique that more closely resembles a tunneling
+   mechanism, DoH nevertheless likely implies DNS over TCP in some
+   sense, if not directly.
+
+A.33.  RFC 8490 - DNS Stateful Operations
+
+   The Proposed Standard [RFC8490] updates the base protocol
+   specification with a new OPCODE to help manage stateful operations in
+   persistent sessions, such as those that might be used by DNS over
+   TCP.
+
+A.34.  RFC 8501 - Reverse DNS in IPv6 for Internet Service Providers
+
+   The Informational document [RFC8501] identifies potential operational
+   challenges with dynamic DNS, including denial-of-service threats.
+   The document suggests TCP may provide some advantages but that
+   updating hosts would need to be explicitly configured to use TCP
+   instead of UDP.
+
+A.35.  RFC 8806 - Running a Root Server Local to a Resolver
+
+   The Informational document [RFC8806] describes how to obtain and
+   operate a local copy of the root zone with examples showing how to
+   pull from authoritative sources using a DNS-over-TCP zone transfer.
+
+A.36.  RFC 8906 - A Common Operational Problem in DNS Servers: Failure
+       to Communicate
+
+   The Best Current Practice document [RFC8906] discusses a number of
+   DNS operational failure scenarios and how to avoid them.  This
+   includes discussions involving DNS-over-TCP queries, EDNS over TCP,
+   and a testing methodology that includes a section on verifying DNS-
+   over-TCP functionality.
+
+A.37.  RFC 8932 - Recommendations for DNS Privacy Service Operators
+
+   The Best Current Practice document [RFC8932] presents privacy
+   considerations to DNS privacy service operators.  These mechanisms
+   sometimes include the use of TCP and are therefore susceptible to
+   information leakage such as TCP-based fingerprinting.  This document
+   also references an earlier draft version of this document.
+
+A.38.  RFC 8945 - Secret Key Transaction Authentication for DNS (TSIG)
+
+   The Internet Standard [RFC8945] recommends that a client use TCP if
+   truncated TSIG messages are received.
+
+Acknowledgments
+
+   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 between what the community has
+   historically said and did.  Thanks to all the NANOG 63 attendees who
+   provided feedback for an early talk on this subject.
+
+   The following individuals provided an array of feedback to help
+   improve this document: Joe Abley, Piet Barber, Sara Dickinson, Tony
+   Finch, Bob Harold, Paul Hoffman, Geoff Huston, Tatuya Jinmei, Puneet
+   Sood, and Richard Wilhelm.  The authors are also indebted to the
+   contributions stemming from discussion in the TCPM Working Group
+   meeting at IETF 104.  Any remaining errors or imperfections are the
+   sole responsibility of the document authors.
+
+Authors' Addresses
+
+   John Kristoff
+   Dataplane.org
+   Chicago, IL 60605
+   United States of America
+   Phone: +1 312 493 0305
+   Email: jtk@dataplane.org
+   URI:   https://dataplane.org/jtk/
+
+
+   Duane Wessels
+   Verisign
+   12061 Bluemont Way
+   Reston, VA 20190
+   United States of America
+   Phone: +1 703 948 3200
+   Email: dwessels@verisign.com
+   URI:   https://verisign.com