1 Internet Engineering Task Force (IETF)                       J. Kristoff   
    2 Request for Comments: 9210                                 Dataplane.org   
    3 BCP: 235                                                      D. Wessels   
    4 Updates: 1123, 1536                                             Verisign   
    5 Category: Best Current Practice                               March 2022   
    6 ISSN: 2070-1721                                                            
    9            DNS Transport over TCP - Operational Requirements               
   11 Abstract                                                                   
   13    This document updates RFCs 1123 and 1536.  This document requires the   
   14    operational practice of permitting DNS messages to be carried over      
   15    TCP on the Internet as a Best Current Practice.  This operational       
   16    requirement is aligned with the implementation requirements in RFC      
   17    7766.  The use of TCP includes both DNS over unencrypted TCP as well    
   18    as over an encrypted TLS session.  The document also considers the      
   19    consequences of this form of DNS communication and the potential        
   20    operational issues that can arise when this Best Current Practice is    
   21    not upheld.                                                             
   23 Status of This Memo                                                        
   25    This memo documents an Internet Best Current Practice.                  
   27    This document is a product of the Internet Engineering Task Force       
   28    (IETF).  It represents the consensus of the IETF community.  It has     
   29    received public review and has been approved for publication by the     
   30    Internet Engineering Steering Group (IESG).  Further information on     
   31    BCPs is available in Section 2 of RFC 7841.                             
   33    Information about the current status of this document, any errata,      
   34    and how to provide feedback on it may be obtained at                    
   35    https://www.rfc-editor.org/info/rfc9210.                                
   37 Copyright Notice                                                           
   39    Copyright (c) 2022 IETF Trust and the persons identified as the         
   40    document authors.  All rights reserved.                                 
   42    This document is subject to BCP 78 and the IETF Trust's Legal           
   43    Provisions Relating to IETF Documents                                   
   44    (https://trustee.ietf.org/license-info) in effect on the date of        
   45    publication of this document.  Please review these documents            
   46    carefully, as they describe your rights and restrictions with respect   
   47    to this document.  Code Components extracted from this document must    
   48    include Revised BSD License text as described in Section 4.e of the     
   49    Trust Legal Provisions and are provided without warranty as described   
   50    in the Revised BSD License.                                             
   52 Table of Contents                                                          
   54    1.  Introduction                                                        
   55      1.1.  Requirements Language                                           
   56    2.  History of DNS over TCP                                             
   57      2.1.  Uneven Transport Usage and Preference                           
   58      2.2.  Waiting for Large Messages and Reliability                      
   59      2.3.  EDNS(0)                                                         
   60      2.4.  Fragmentation and Truncation                                    
   61      2.5.  "Only Zone Transfers Use TCP"                                   
   62      2.6.  Reuse, Pipelining, and Out-of-Order Processing                  
   63    3.  DNS-over-TCP Requirements                                           
   64    4.  Network and System Considerations                                   
   65      4.1.  Connection Establishment and Admission                          
   66      4.2.  Connection Management                                           
   67      4.3.  Connection Termination                                          
   68      4.4.  DNS over TLS                                                    
   69      4.5.  Defaults and Recommended Limits                                 
   70    5.  DNS-over-TCP Filtering Risks                                        
   71      5.1.  Truncation, Retries, and Timeouts                               
   72      5.2.  DNS Root Zone KSK Rollover                                      
   73    6.  Logging and Monitoring                                              
   74    7.  IANA Considerations                                                 
   75    8.  Security Considerations                                             
   76    9.  Privacy Considerations                                              
   77    10. References                                                          
   78      10.1.  Normative References                                           
   79      10.2.  Informative References                                         
   80    Appendix A.  RFCs Related to DNS Transport over TCP                     
   82      A.2.  RFC 1536 - Common DNS Implementation Errors and Suggested       
   83             Fixes                                                          
   84      A.3.  RFC 1995 - Incremental Zone Transfer in DNS                     
   85      A.4.  RFC 1996 - A Mechanism for Prompt Notification of Zone          
   86             Changes (DNS NOTIFY)                                           
   87      A.5.  RFC 2181 - Clarifications to the DNS Specification              
   88      A.6.  RFC 2694 - DNS extensions to Network Address Translators        
   89             (DNS_ALG)                                                      
   90      A.7.  RFC 3225 - Indicating Resolver Support of DNSSEC                
   91      A.8.  RFC 3226 - DNSSEC and IPv6 A6 aware server/resolver message     
   92             size requirements                                              
   93      A.9.  RFC 4472 - Operational Considerations and Issues with IPv6      
   94             DNS                                                            
   95      A.10. RFC 5452 - Measures for Making DNS More Resilient against       
   96             Forged Answers                                                 
   97      A.11. RFC 5507 - Design Choices When Expanding the DNS                
   98      A.12. RFC 5625 - DNS Proxy Implementation Guidelines                  
   99      A.13. RFC 5936 - DNS Zone Transfer Protocol (AXFR)                    
  100      A.14. RFC 7534 - AS112 Nameserver Operations                          
  101      A.15. RFC 6762 - Multicast DNS                                        
  102      A.16. RFC 6891 - Extension Mechanisms for DNS (EDNS(0))               
  103      A.17. IAB RFC 6950 - Architectural Considerations on Application      
  104             Features in the DNS                                            
  105      A.18. RFC 7477 - Child-to-Parent Synchronization in DNS               
  106      A.19. RFC 7720 - DNS Root Name Service Protocol and Deployment        
  107             Requirements                                                   
  108      A.20. RFC 7766 - DNS Transport over TCP - Implementation              
  109             Requirements                                                   
  110      A.21. RFC 7828 - The edns-tcp-keepalive EDNS(0) Option                
  111      A.22. RFC 7858 - Specification for DNS over Transport Layer           
  112             Security (TLS)                                                 
  113      A.23. RFC 7873 - Domain Name System (DNS) Cookies                     
  114      A.24. RFC 7901 - CHAIN Query Requests in DNS                          
  115      A.25. RFC 8027 - DNSSEC Roadblock Avoidance                           
  116      A.26. RFC 8094 - DNS over Datagram Transport Layer Security           
  117             (DTLS)                                                         
  118      A.27. RFC 8162 - Using Secure DNS to Associate Certificates with      
  119             Domain Names for S/MIME                                        
  120      A.28. RFC 8324 - DNS Privacy, Authorization, Special Uses,            
  121             Encoding, Characters, Matching, and Root Structure: Time for   
  122             Another Look?                                                  
  123      A.29. RFC 8467 - Padding Policies for Extension Mechanisms for        
  124             DNS (EDNS(0))                                                  
  125      A.30. RFC 8482 - Providing Minimal-Sized Responses to DNS Queries     
  126             That Have QTYPE=ANY                                            
  127      A.31. RFC 8483 - Yeti DNS Testbed                                     
  128      A.32. RFC 8484 - DNS Queries over HTTPS (DoH)                         
  129      A.33. RFC 8490 - DNS Stateful Operations                              
  130      A.34. RFC 8501 - Reverse DNS in IPv6 for Internet Service             
  131             Providers                                                      
  132      A.35. RFC 8806 - Running a Root Server Local to a Resolver            
  133      A.36. RFC 8906 - A Common Operational Problem in DNS Servers:         
  134             Failure to Communicate                                         
  135      A.37. RFC 8932 - Recommendations for DNS Privacy Service              
  136             Operators                                                      
  137      A.38. RFC 8945 - Secret Key Transaction Authentication for DNS        
  138             (TSIG)                                                         
  139    Acknowledgments                                                         
  140    Authors' Addresses                                                      
  142 1.  Introduction                                                           
  144    DNS messages are delivered using UDP or TCP communications.  While      
  145    most DNS transactions are carried over UDP, some operators have been    
  146    led to believe that any DNS-over-TCP traffic is unwanted or             
  147    unnecessary for general DNS operation.  When DNS over TCP has been      
  148    restricted, a variety of communication failures and debugging           
  149    challenges often arise.  As DNS and new naming system features have     
  150    evolved, TCP as a transport has become increasingly important for the   
  151    correct and safe operation of an Internet DNS.  Reflecting modern       
  152    usage, the DNS standards declare that support for TCP is a required     
  153    part of the DNS implementation specifications [RFC7766].  This          
  154    document is the equivalent of formal requirements for the operational   
  155    community, encouraging system administrators, network engineers, and    
  156    security staff to ensure DNS-over-TCP communications support is on      
  157    par with DNS-over-UDP communications.  It updates [RFC1123],            
  158    Section to clarify that all DNS resolvers and recursive         
  159    servers MUST support and service both TCP and UDP queries and also      
  160    updates [RFC1536] to remove the misconception that TCP is only useful   
  161    for zone transfers.                                                     
  163 1.1.  Requirements Language                                                
  165    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  167    "OPTIONAL" in this document are to be interpreted as described in       
  168    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all      
  169    capitals, as shown here.                                                
  171 2.  History of DNS over TCP                                                
  173    The curious state of disagreement between operational best practices    
  174    and guidance for DNS transport protocols derives from conflicting       
  175    messages operators have received from other operators, implementors,    
  176    and even the IETF.  Sometimes these mixed signals have been explicit;   
  177    on other occasions, conflicting messages have been implicit.  This      
  178    section presents an interpretation of the storied and conflicting       
  179    history that led to this document.  This section is included for        
  180    informational purposes only.                                            
  182 2.1.  Uneven Transport Usage and Preference                                
  184    In the original suite of DNS specifications, [RFC1034] and [RFC1035]    
  185    clearly specify that DNS messages could be carried in either UDP or     
  186    TCP, but they also state that there is a preference for UDP as the      
  187    best transport for queries in the general case.  As stated in           
  188    [RFC1035]:                                                              
  190    |  While virtual circuits can be used for any DNS activity, datagrams   
  191    |  are preferred for queries due to their lower overhead and better     
  192    |  performance.                                                         
  194    Another early, important, and influential document, [RFC1123], marks    
  195    the preference for a transport protocol more explicitly:                
  197    |  DNS resolvers and recursive servers MUST support UDP, and SHOULD     
  198    |  support TCP, for sending (non-zone-transfer) queries.                
  200    and it further stipulates that:                                         
  202    |  A name server MAY limit the resources it devotes to TCP queries,     
  203    |  but it SHOULD NOT refuse to service a TCP query just because it      
  204    |  would have succeeded with UDP.                                       
  206    Culminating in [RFC1536], DNS over TCP came to be associated            
  207    primarily with the zone transfer mechanism, while most DNS queries      
  208    and responses were seen as the dominion of UDP.                         
  210 2.2.  Waiting for Large Messages and Reliability                           
  212    In the original specifications, the maximum DNS-over-UDP message size   
  213    was enshrined at 512 bytes.  However, even while [RFC1123] prefers      
  214    UDP for non-zone transfer queries, it foresaw that DNS over TCP would   
  215    become more popular in the future to overcome this limitation:          
  217    |  [...] it is also clear that some new DNS record types defined in     
  218    |  the future will contain information exceeding the 512 byte limit     
  219    |  that applies to UDP, and hence will require TCP.                     
  221    At least two new, widely anticipated developments were set to elevate   
  222    the need for DNS-over-TCP transactions.  The first was dynamic          
  223    updates defined in [RFC2136], and the second was the set of             
  224    extensions collectively known as "DNSSEC", whose operational            
  225    considerations were originally given in [RFC2541] (note that            
  226    [RFC2541] has been obsoleted by [RFC6781]).  The former suggests that   
  228    |  ...requestors who require an accurate response code must use TCP.    
  230    while the latter warns that                                             
  232    |  ... larger keys increase the size of the KEY and SIG RRs.  This      
  233    |  increases the chance of DNS UDP packet overflow and the possible     
  234    |  necessity for using higher overhead TCP in responses.                
  236    Yet, defying some expectations, DNS over TCP remained little used in    
  237    real traffic across the Internet in the late 1990s.  Dynamic updates    
  238    saw little deployment between autonomous networks.  Around the time     
  239    DNSSEC was first defined, another new feature helped solidify UDP       
  240    transport dominance for message transactions.                           
  242 2.3.  EDNS(0)                                                              
  244    In 1999, the IETF published the Extension Mechanisms for DNS            
  245    (EDNS(0)) in [RFC2671] (which was obsoleted by [RFC6891] in 2013).      
  246    That document standardized a way for communicating DNS nodes to         
  247    perform rudimentary capabilities negotiation.  One such capability      
  248    written into the base specification and present in every EDNS(0)-       
  249    compatible message is the value of the maximum UDP payload size the     
  250    sender can support.  This unsigned 16-bit field specifies, in bytes,    
  251    the maximum (possibly fragmented) DNS message size a node is capable    
  252    of receiving over UDP.  In practice, typical values are a subset of     
  253    the 512- to 4096-byte range.  EDNS(0) became widely deployed over the   
  254    next several years, and numerous surveys (see [CASTRO2010] and          
  255    [NETALYZR]) have shown that many systems support larger UDP MTUs with   
  256    EDNS(0).                                                                
  258    The natural effect of EDNS(0) deployment meant DNS messages larger      
  259    than 512 bytes would be less reliant on TCP than they might otherwise   
  260    have been.  While a non-negligible population of DNS systems lacked     
  261    EDNS(0) or fell back to TCP when necessary, DNS clients still           
  262    strongly prefer UDP to TCP.  For example, as of 2014, DNS-over-TCP      
  263    transactions remained a very small fraction of overall DNS traffic      
  264    received by root name servers [VERISIGN].                               
  266 2.4.  Fragmentation and Truncation                                         
  268    Although EDNS(0) provides a way for endpoints to signal support for     
  269    DNS messages exceeding 512 bytes, the realities of a diverse and        
  270    inconsistently deployed Internet may result in some large messages      
  271    being unable to reach their destination.  Any IP datagram whose size    
  272    exceeds the MTU of a link it transits will be fragmented and then       
  273    reassembled by the receiving host.  Unfortunately, it is not uncommon   
  274    for middleboxes and firewalls to block IP fragments.  If one or more    
  275    fragments do not arrive, the application does not receive the           
  276    message, and the request times out.                                     
  278    For IPv4-connected hosts, the MTU is often an Ethernet payload size     
  279    of 1500 bytes.  This means that the largest unfragmented UDP DNS        
  280    message that can be sent over IPv4 is likely 1472 bytes, although       
  281    tunnel encapsulation may reduce that maximum message size in some       
  282    cases.                                                                  
  284    For IPv6, the situation is a little more complicated.  First, IPv6      
  285    headers are 40 bytes (versus 20 without options in IPv4).  Second,      
  286    approximately one-third of DNS recursive resolvers use the minimum      
  287    MTU of 1280 bytes [APNIC].  Third, fragmentation in IPv6 can only be    
  288    done by the host originating the datagram.  The need to fragment is     
  289    conveyed in an ICMPv6 "Packet Too Big" message.  The originating host   
  290    indicates a fragmented datagram with IPv6 extension headers.            
  291    Unfortunately, it is quite common for both ICMPv6 and IPv6 extension    
  292    headers to be blocked by middleboxes.  According to [HUSTON], some      
  293    35% of IPv6-capable recursive resolvers were unable to receive a        
  294    fragmented IPv6 packet.  When the originating host receives a signal    
  295    that fragmentation is required, it is expected to populate its path     
  296    MTU cache for that destination.  The application will then retry the    
  297    query after a timeout since the host does not generally retain copies   
  298    of messages sent over UDP for potential retransmission.                 
  300    The practical consequence of all this is that DNS requestors must be    
  301    prepared to retry queries with different EDNS(0) maximum message size   
  302    values.  Administrators of [BIND] are likely to be familiar with        
  303    seeing the following message in their system logs: "success resolving   
  304    ... after reducing the advertised EDNS(0) UDP packet size to 512        
  305    octets".                                                                
  307    Often, reducing the EDNS(0) UDP packet size leads to a successful       
  308    response.  That is, the necessary data fits within the smaller          
  309    message size.  However, when the data does not fit, the server sets     
  310    the truncated flag in its response, indicating the client should        
  311    retry over TCP to receive the whole response.  This is undesirable      
  312    from the client's point of view because it adds more latency and is     
  313    potentially undesirable from the server's point of view due to the      
  314    increased resource requirements of TCP.                                 
  316    Note that a receiver is unable to differentiate between packets lost    
  317    due to congestion and packets (fragments) intentionally dropped by      
  318    firewalls or middleboxes.  Over network paths with non-trivial          
  319    amounts of packet loss, larger, fragmented DNS responses are more       
  320    likely to never arrive and time out compared to smaller, unfragmented   
  321    responses.  Clients might be misled into retrying queries with          
  322    different EDNS(0) UDP packet size values for the wrong reason.          
  324    The issues around fragmentation, truncation, and TCP are driving        
  325    certain implementation and policy decisions in the DNS.  Notably,       
  326    Cloudflare implemented a technique that minimizes the number of         
  327    DNSSEC denial-of-existence records (for its online signing platform)    
  328    [CLOUDFLARE] and uses an Elliptic Curve Digital Signature Algorithm     
  329    (ECDSA) such that its signed responses fit easily in 512 bytes.  The    
  330    Key Signing Key (KSK) Rollover Design Team [DESIGNTEAM] spent a lot     
  331    of time thinking and worrying about response sizes.  There is growing   
  332    sentiment in the DNSSEC community that RSA key sizes beyond 2048 bits   
  333    are impractical and that critical infrastructure zones should           
  334    transition to elliptic curve algorithms to keep response sizes          
  335    manageable [ECDSA].                                                     
  337    More recently, renewed security concerns about fragmented DNS           
  338    messages (see [AVOID_FRAGS] and [FRAG_POISON]) are leading              
  339    implementors to consider smaller responses and lower default EDNS(0)    
  340    UDP payload size values for both queriers and responders                
  341    [FLAGDAY2020].                                                          
  343 2.5.  "Only Zone Transfers Use TCP"                                        
  345    Today, the majority of the DNS community expects, or at least has a     
  346    desire, to see DNS-over-TCP transactions occur without interference     
  347    [FLAGDAY2020].  However, there has also been a long-held belief by      
  348    some operators, particularly for security-related reasons, that DNS-    
  349    over-TCP services should be purposely limited or not provided at all    
  350    [CHES94] [DJBDNS].  A popular meme is that DNS over TCP is only ever    
  351    used for zone transfers and is generally unnecessary otherwise, with    
  352    filtering all DNS-over-TCP traffic even described as a best practice.   
  354    The position on restricting DNS over TCP had some justification given   
  355    that historical implementations of DNS name servers provided very       
  356    little in the way of TCP connection management (for example, see        
  357    Section 6.1.2 of [RFC7766] for more details).  However, modern          
  358    standards and implementations are nearing parity with the more          
  359    sophisticated TCP management techniques employed by, for example,       
  360    HTTP(S) servers and load balancers.                                     
  362 2.6.  Reuse, Pipelining, and Out-of-Order Processing                       
  364    The idea that a TCP connection can support multiple transactions goes   
  365    back as far as [RFC0883], which states: "Multiple messages may be       
  366    sent over a virtual circuit."  Although [RFC1035], which updates the    
  367    former, omits this particular detail, it has been generally accepted    
  368    that a TCP connection can be used for more than one query and           
  369    response.                                                               
  371    [RFC5966] clarifies that servers are not required to preserve the       
  372    order of queries and responses over any transport.  [RFC7766], which    
  373    updates the former, further encourages query pipelining over TCP to     
  374    achieve performance on par with UDP.  A server that sends out-of-       
  375    order responses to pipelined queries avoids head-of-line blocking       
  376    when the response for a later query is ready before the response to     
  377    an earlier query.                                                       
  379    However, TCP can potentially suffer from a different head-of-line       
  380    blocking problem due to packet loss.  Since TCP itself enforces         
  381    ordering, a single lost segment delays delivery of data in any          
  382    following segments until the lost segment is retransmitted and          
  383    successfully received.                                                  
  385 3.  DNS-over-TCP Requirements                                              
  387    An average increase in DNS message size (e.g., due to DNSSEC), the      
  388    continued development of new DNS features (Appendix A), and a denial-   
  389    of-service mitigation technique (Section 8) all show that DNS-over-     
  390    TCP transactions are as important to the correct and safe operation     
  391    of the Internet DNS as ever, if not more so.  Furthermore, there has    
  392    been research that argues connection-oriented DNS transactions may      
  393    provide security and privacy advantages over UDP transport [TDNS].      
  394    In fact, the standard for DNS over TLS [RFC7858] is just this sort of   
  395    specification.  Therefore, this document makes explicit that it is      
  396    undesirable for network operators to artificially inhibit DNS-over-     
  397    TCP transport.                                                          
  399    Section of [RFC1123] is updated as follows:                     
  401    OLD:                                                                    
  403    |  DNS resolvers and recursive servers MUST support UDP, and SHOULD     
  404    |  support TCP, for sending (non-zone-transfer) queries.                
  406    NEW:                                                                    
  408    |  All DNS resolvers and servers MUST support and service both UDP      
  409    |  and TCP queries.                                                     
  411    Note that:                                                              
  413    *  DNS servers (including forwarders) MUST support and service TCP      
  414       for receiving queries so that clients can reliably receive           
  415       responses that are larger than what either side considers too        
  416       large for UDP.                                                       
  418    *  DNS clients MUST support TCP for sending queries so that they can    
  419       retry truncated UDP responses as necessary.                          
  421    Furthermore, the requirement in Section of [RFC1123] around     
  422    limiting the resources a server devotes to queries is hereby updated:   
  424    OLD:                                                                    
  426    |  A name server MAY limit the resources it devotes to TCP queries,     
  427    |  but it SHOULD NOT refuse to service a TCP query just because it      
  428    |  would have succeeded with UDP.                                       
  430    NEW:                                                                    
  432    |  A name server MAY limit the resources it devotes to queries, but     
  433    |  it MUST NOT refuse to service a query just because it would have     
  434    |  succeeded with another transport protocol.                           
  436    Lastly, Section 1 of [RFC1536] is updated to eliminate the              
  437    misconception that TCP is only useful for zone transfers:               
  439    OLD:                                                                    
  441    |  DNS implements the classic request-response scheme of client-        
  442    |  server interaction.  UDP is, therefore, the chosen protocol for      
  443    |  communication though TCP is used for zone transfers.                 
  445    NEW:                                                                    
  447    |  DNS implements the classic request-response scheme of client-        
  448    |  server interaction.                                                  
  450    The filtering of DNS over TCP is harmful in the general case.  DNS      
  451    resolver and server operators MUST support and provide DNS service      
  452    over both UDP and TCP transports.  Likewise, network operators MUST     
  453    allow DNS service over both UDP and TCP transports.  It is              
  454    acknowledged that DNS-over-TCP service can pose operational             
  455    challenges that are not present when running DNS over UDP alone, and    
  456    vice versa.  However, the potential damage incurred by prohibiting      
  457    DNS-over-TCP service is more detrimental to the continued utility and   
  458    success of the DNS than when its usage is allowed.                      
  460 4.  Network and System Considerations                                      
  462    This section describes measures that systems and applications can       
  463    take to optimize performance over TCP and to protect themselves from    
  464    TCP-based resource exhaustion and attacks.                              
  466 4.1.  Connection Establishment and Admission                               
  468    Resolvers and other DNS clients should be aware that some servers       
  469    might not be reachable over TCP.  For this reason, clients MAY track    
  470    and limit the number of TCP connections and connection attempts to a    
  471    single server.  Reachability problems can be caused by network          
  472    elements close to the server, close to the client, or anywhere along    
  473    the path between them.  Mobile clients that cache connection failures   
  474    MAY do so on a per-network basis or MAY clear such a cache upon         
  475    change of network.                                                      
  477    Additionally, DNS clients MAY enforce a short timeout on                
  478    unestablished connections rather than rely on the host operating        
  479    system's TCP connection timeout, which is often around 60-120 seconds   
  480    (i.e., due to an initial retransmission timeout of 1 second, the        
  481    exponential back-off rules of [RFC6298], and a limit of six retries     
  482    as is the default in Linux).                                            
  484    The SYN flooding attack is a denial-of-service method affecting hosts   
  485    that run TCP server processes [RFC4987].  This attack can be very       
  486    effective if not mitigated.  One of the most effective mitigation       
  487    techniques is SYN cookies, described in Section 3.6 of [RFC4987],       
  488    which allows the server to avoid allocating any state until the         
  489    successful completion of the three-way handshake.                       
  491    Services not intended for use by the public Internet, such as most      
  492    recursive name servers, SHOULD be protected with access controls.       
  493    Ideally, these controls are placed in the network, well before any      
  494    unwanted TCP packets can reach the DNS server host or application.      
  495    If this is not possible, the controls can be placed in the              
  496    application itself.  In some situations (e.g., attacks), it may be      
  497    necessary to deploy access controls for DNS services that should        
  498    otherwise be globally reachable.  See also [RFC5358].                   
  500    The FreeBSD and NetBSD operating systems have an "accept filter"        
  501    feature ([accept_filter]) that postpones delivery of TCP connections    
  502    to applications until a complete, valid request has been received.      
  503    The dns_accf(9) filter ensures that a valid DNS message is received.    
  504    If not, the bogus connection never reaches the application.  The        
  505    Linux TCP_DEFER_ACCEPT feature, while more limited in scope, can        
  506    provide some of the same benefits as the BSD accept filter feature.     
  507    These features are implemented as low-level socket options and are      
  508    not activated automatically.  If applications wish to use these         
  509    features, they need to make specific calls to set the right options,    
  510    and administrators may also need to configure the applications to       
  511    appropriately use the features.                                         
  513    Per [RFC7766], applications and administrators are advised to           
  514    remember that TCP MAY be used before sending any UDP queries.           
  515    Networks and applications MUST NOT be configured to refuse TCP          
  516    queries that were not preceded by a UDP query.                          
  518    TCP Fast Open (TFO) [RFC7413] allows TCP clients to shorten the         
  519    handshake for subsequent connections to the same server.  TFO saves     
  520    one round-trip time in the connection setup.  DNS servers SHOULD        
  521    enable TFO when possible.  Furthermore, DNS servers clustered behind    
  522    a single service address (e.g., anycast or load balancing) SHOULD       
  523    either use the same TFO server key on all instances or disable TFO      
  524    for all members of the cluster.                                         
  526    DNS clients MAY also enable TFO.  At the time of this writing, it is    
  527    not implemented or is disabled by default on some operating systems.    
  528    [WIKIPEDIA_TFO] describes applications and operating systems that       
  529    support TFO.                                                            
  531 4.2.  Connection Management                                                
  533    Since host memory for TCP state is a finite resource, DNS clients and   
  534    servers SHOULD actively manage their connections.  Applications that    
  535    do not actively manage their connections can encounter resource         
  536    exhaustion leading to denial of service.  For DNS, as in other          
  537    protocols, there is a trade-off between keeping connections open for    
  538    potential future use and the need to free up resources for new          
  539    connections that will arrive.                                           
  541    Operators of DNS server software SHOULD be aware that operating         
  542    system and application vendors MAY impose a limit on the total number   
  543    of established connections.  These limits may be designed to protect    
  544    against DDoS attacks or performance degradation.  Operators SHOULD      
  545    understand how to increase these limits if necessary and the            
  546    consequences of doing so.  Limits imposed by the application SHOULD     
  547    be lower than limits imposed by the operating system so that the        
  548    application can apply its own policy to connection management, such     
  549    as closing the oldest idle connections first.                           
  551    DNS server software MAY provide a configurable limit on the number of   
  552    established connections per source IP address or subnet.  This can be   
  553    used to ensure that a single or small set of users cannot consume all   
  554    TCP resources and deny service to other users.  Note, however, that     
  555    if this limit is enabled, it possibly limits client performance while   
  556    leaving some TCP resources unutilized.  Operators SHOULD be aware of    
  557    these trade-offs and ensure this limit, if configured, is set           
  558    appropriately based on the number and diversity of their users and      
  559    whether users connect from unique IP addresses or through a shared      
  560    Network Address Translator (NAT) [RFC3022].                             
  562    DNS server software SHOULD provide a configurable timeout for idle      
  563    TCP connections.  This can be used to free up resources for new         
  564    connections and to ensure that idle connections are eventually          
  565    closed.  At the same time, it possibly limits client performance        
  566    while leaving some TCP resources unutilized.  For very busy name        
  567    servers, this might be set to a low value, such as a few seconds.       
  568    For less busy servers, it might be set to a higher value, such as       
  569    tens of seconds.  DNS clients and servers SHOULD signal their timeout   
  570    values using the edns-tcp-keepalive EDNS(0) option [RFC7828].           
  572    DNS server software MAY provide a configurable limit on the number of   
  573    transactions per TCP connection.  This can help protect against         
  574    unfair connection use (e.g., not releasing connection slots to other    
  575    clients) and network evasion attacks.                                   
  577    Similarly, DNS server software MAY provide a configurable limit on      
  578    the total duration of a TCP connection.  This can help protect          
  579    against unfair connection use, slow read attacks, and network evasion   
  580    attacks.                                                                
  582    Since clients may not be aware of server-imposed limits, clients        
  583    utilizing TCP for DNS need to always be prepared to re-establish        
  584    connections or otherwise retry outstanding queries.                     
  586 4.3.  Connection Termination                                               
  588    The TCP peer that initiates a connection close retains the socket in    
  589    the TIME_WAIT state for some amount of time, possibly a few minutes.    
  590    It is generally preferable for clients to initiate the close of a TCP   
  591    connection so that busy servers do not accumulate many sockets in the   
  592    TIME_WAIT state, which can cause performance problems or even denial    
  593    of service.  The edns-tcp-keepalive EDNS(0) option [RFC7828] can be     
  594    used to encourage clients to close connections.                         
  596    On systems where large numbers of sockets in TIME_WAIT are observed     
  597    (as either a client or a server) and are affecting an application's     
  598    performance, it may be tempting to tune local TCP parameters.  For      
  599    example, the Linux kernel has a "sysctl" parameter named                
  600    net.ipv4.tcp_tw_reuse, which allows connections in the TIME_WAIT        
  601    state to be reused in specific circumstances.  Note, however, that      
  602    this affects only outgoing (client) connections and has no impact on    
  603    servers.  In most cases, it is NOT RECOMMENDED to change parameters     
  604    related to the TIME_WAIT state.  It should only be done by those with   
  605    detailed knowledge of both TCP and the affected application.            
  607 4.4.  DNS over TLS                                                         
  609    DNS messages may be sent over TLS to provide privacy between stubs      
  610    and recursive resolvers.  [RFC7858] is a Standards Track document       
  611    describing how this works.  Although DNS over TLS utilizes TCP port     
  612    853 instead of port 53, this document applies equally well to DNS       
  613    over TLS.  Note, however, that DNS over TLS is only defined between     
  614    stubs and recursives at the time of this writing.                       
  616    The use of TLS places even stronger operational burdens on DNS          
  617    clients and servers.  Cryptographic functions for authentication and    
  618    encryption require additional processing.  Unoptimized connection       
  619    setup with TLS 1.3 [RFC8446] takes one additional round trip compared   
  620    to TCP.  Connection setup times can be reduced with TCP Fast Open and   
  621    TLS False Start [RFC7918] for TLS 1.2.  TLS 1.3 session resumption      
  622    does not reduce round-trip latency because no application profile for   
  623    use of TLS 0-RTT data with DNS has been published at the time of this   
  624    writing.  However, TLS session resumption can reduce the number of      
  625    cryptographic operations, and in TLS 1.2, session resumption does       
  626    reduce the number of additional round trips from two to one.            
  628 4.5.  Defaults and Recommended Limits                                      
  630    A survey of features and defaults was conducted for popular open-       
  631    source DNS server implementations at the time of writing.  This         
  632    section documents those defaults and makes recommendations for          
  633    configurable limits that can be used in the absence of any other        
  634    information.  Any recommended values in this document are only          
  635    intended as a starting point for administrators that are unsure of      
  636    what sorts of limits might be reasonable.  Operators SHOULD use         
  637    application-specific monitoring, system logs, and system monitoring     
  638    tools to gauge whether their service is operating within or exceeding   
  639    these limits and adjust accordingly.                                    
  641    Most open-source DNS server implementations provide a configurable      
  642    limit on the total number of established connections.  Default values   
  643    range from 20 to 150.  In most cases, where the majority of queries     
  644    take place over UDP, 150 is a reasonable limit.  For services or        
  645    environments where most queries take place over TCP or TLS, 5000 is a   
  646    more appropriate limit.                                                 
  648    Only some open-source implementations provide a way to limit the        
  649    number of connections per source IP address or subnet, but the          
  650    default is to have no limit.  For environments or situations where it   
  651    may be necessary to enable this limit, 25 connections per source IP     
  652    address is a reasonable starting point.  The limit should be            
  653    increased when aggregated by subnet or for services where most          
  654    queries take place over TCP or TLS.                                     
  656    Most open-source implementations provide a configurable idle timeout    
  657    on connections.  Default values range from 2 to 30 seconds.  In most    
  658    cases, 10 seconds is a reasonable default for this limit.  Longer       
  659    timeouts improve connection reuse, but busy servers may need to use a   
  660    lower limit.                                                            
  662    Only some open-source implementations provide a way to limit the        
  663    number of transactions per connection, but the default is to have no    
  664    limit.  This document does not offer advice on particular values for    
  665    such a limit.                                                           
  667    Only some open-source implementations provide a way to limit the        
  668    duration of connection, but the default is to have no limit.  This      
  669    document does not offer advice on particular values for such a limit.   
  671 5.  DNS-over-TCP Filtering Risks                                           
  673    Networks that filter DNS over TCP risk losing access to significant     
  674    or important pieces of the DNS namespace.  For a variety of reasons,    
  675    a DNS answer may require a DNS-over-TCP query.  This may include        
  676    large message sizes, lack of EDNS(0) support, or DDoS mitigation        
  677    techniques (including Response Rate Limiting [RRL]); additionally,      
  678    perhaps some future capability that is as yet unforeseen will also      
  679    demand TCP transport.                                                   
  681    For example, [RFC7901] describes a latency-avoiding technique that      
  682    sends extra data in DNS responses.  This makes responses larger and     
  683    potentially increases the effectiveness of DDoS reflection attacks.     
  684    The specification mandates the use of TCP or DNS cookies [RFC7873].     
  686    Even if any or all particular answers have consistently been returned   
  687    successfully with UDP in the past, this continued behavior cannot be    
  688    guaranteed when DNS messages are exchanged between autonomous           
  689    systems.  Therefore, filtering of DNS over TCP is considered harmful    
  690    and contrary to the safe and successful operation of the Internet.      
  691    This section enumerates some of the known risks at the time of this     
  692    writing when networks filter DNS over TCP.                              
  694 5.1.  Truncation, Retries, and Timeouts                                    
  696    Networks that filter DNS over TCP may inadvertently cause problems      
  697    for third-party resolvers as experienced by [TOYAMA].  For example, a   
  698    resolver receives queries for a moderately popular domain.  The         
  699    resolver forwards the queries to the domain's authoritative name        
  700    servers, but those servers respond with the TC bit set.  The resolver   
  701    retries over TCP, but the authoritative server blocks DNS over TCP.     
  702    The pending connections consume resources on the resolver until they    
  703    time out.  If the number and frequency of these truncated-and-then-     
  704    blocked queries are sufficiently high, the resolver wastes valuable     
  705    resources on queries that can never be answered.  This condition is     
  706    generally not easily or completely mitigated by the affected DNS        
  707    resolver operator.                                                      
  709 5.2.  DNS Root Zone KSK Rollover                                           
  711    The plans for deploying DNSSEC KSK for the root zone highlighted a      
  712    potential problem in retrieving the root zone key set [LEWIS].          
  713    During some phases of the KSK rollover process, root zone DNSKEY        
  714    responses were larger than 1280 bytes, the IPv6 minimum MTU for links   
  715    carrying IPv6 traffic [RFC8200].  There was some concern that any DNS   
  716    server unable to receive large DNS messages over UDP, or any DNS        
  717    message over TCP, would experience disruption while performing DNSSEC   
  718    validation [KSK_ROLLOVER_ARCHIVES].                                     
  720    However, during the year-long postponement of the KSK rollover, there   
  721    were no reported problems that could be attributed to the 1414 octet    
  722    DNSKEY response when both the old and new keys were published in the    
  723    zone.  Additionally, there were no reported problems during the two-    
  724    month period when the old key was published as revoked and the DNSKEY   
  725    response was 1425 octets in size [ROLL_YOUR_ROOT].                      
  727 6.  Logging and Monitoring                                                 
  729    Developers of applications that log or monitor DNS SHOULD NOT ignore    
  730    TCP due to the perception that it is rarely used or is hard to          
  731    process.  Operators SHOULD ensure that their monitoring and logging     
  732    applications properly capture DNS messages over TCP.  Otherwise,        
  733    attacks, exfiltration attempts, and normal traffic may go undetected.   
  735    DNS messages over TCP are in no way guaranteed to arrive in single      
  736    segments.  In fact, a clever attacker might attempt to hide certain     
  737    messages by forcing them over very small TCP segments.  Applications    
  738    that capture network packets (e.g., with libpcap [libpcap]) SHOULD      
  739    implement and perform full TCP stream reassembly and analyze the        
  740    reassembled stream instead of the individual packets.  Otherwise,       
  741    they are vulnerable to network evasion attacks [phrack].                
  742    Furthermore, such applications need to protect themselves from          
  743    resource exhaustion attacks by limiting the amount of memory            
  744    allocated to tracking unacknowledged connection state data.  dnscap     
  745    [dnscap] is an open-source example of a DNS logging program that        
  746    implements TCP stream reassembly.                                       
  748    Developers SHOULD also keep in mind connection reuse, query             
  749    pipelining, and out-of-order responses when building and testing DNS    
  750    monitoring applications.                                                
  752    As an alternative to packet capture, some DNS server software           
  753    supports dnstap [dnstap] as an integrated monitoring protocol           
  754    intended to facilitate wide-scale DNS monitoring.                       
  756 7.  IANA Considerations                                                    
  758    This document has no IANA actions.                                      
  760 8.  Security Considerations                                                
  762    This document, providing operational requirements, is the companion     
  763    to the implementation requirements of DNS over TCP provided in          
  764    [RFC7766].  The security considerations from [RFC7766] still apply.     
  766    Ironically, returning truncated DNS-over-UDP answers in order to        
  767    induce a client query to switch to DNS over TCP has become a common     
  768    response to source-address-spoofed, DNS denial-of-service attacks       
  769    [RRL].  Historically, operators have been wary of TCP-based attacks,    
  770    but in recent years, UDP-based flooding attacks have proven to be the   
  771    most common protocol attack on the DNS.  Nevertheless, a high rate of   
  772    short-lived DNS transactions over TCP may pose challenges.  In fact,    
  773    [DAI21] details a class of IP fragmentation attacks on DNS              
  774    transactions if the IP Identifier field (16 bits in IPv4 and 32 bits    
  775    in IPv6) can be predicted and a system is coerced to fragment rather    
  776    than retransmit messages.  While many operators have provided DNS-      
  777    over-TCP service for many years without duress, past experience is no   
  778    guarantee of future success.                                            
  780    DNS over TCP is similar to many other Internet TCP services.  TCP       
  781    threats and many mitigation strategies have been well documented in a   
  782    series of documents such as [RFC4953], [RFC4987], [RFC5927], and        
  783    [RFC5961].                                                              
  785    As mentioned in Section 6, applications that implement TCP stream       
  786    reassembly need to limit the amount of memory allocated to connection   
  787    tracking.  A failure to do so could lead to a total failure of the      
  788    logging or monitoring application.  Imposition of resource limits       
  789    creates a trade-off between allowing some stream reassembly to          
  790    continue and allowing some evasion attacks to succeed.                  
  792    This document recommends that DNS servers enable TFO when possible.     
  793    [RFC7413] recommends that a pool of servers behind a load balancer      
  794    with a shared server IP address also share the key used to generate     
  795    Fast Open cookies to prevent inordinate fallback to the three-way       
  796    handshake (3WHS).  This guidance remains accurate but comes with a      
  797    caveat: compromise of one server would reveal this group-shared key     
  798    and allow for attacks involving the other servers in the pool by        
  799    forging invalid Fast Open cookies.                                      
  801 9.  Privacy Considerations                                                 
  803    Since DNS over both UDP and TCP uses the same underlying message        
  804    format, the use of one transport instead of the other does not change   
  805    the privacy characteristics of the message content (i.e., the name      
  806    being queried).  A number of protocols have recently been developed     
  807    to provide DNS privacy, including DNS over TLS [RFC7858], DNS over      
  808    DTLS [RFC8094], DNS over HTTPS [RFC8484], with even more on the way.    
  810    Because TCP is somewhat more complex than UDP, some characteristics     
  811    of a TCP conversation may enable DNS client fingerprinting and          
  812    tracking that is not possible with UDP.  For example, the choice of     
  813    initial sequence numbers, window size, and options might be able to     
  814    identify a particular TCP implementation or even individual hosts       
  815    behind shared resources such as NATs.                                   
  817 10.  References                                                            
  819 10.1.  Normative References                                                
  821    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
  822               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,      
  823               November 1987, <https://www.rfc-editor.org/info/rfc1035>.    
  825    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
  826               Requirement Levels", BCP 14, RFC 2119,                       
  827               DOI 10.17487/RFC2119, March 1997,                            
  828               <https://www.rfc-editor.org/info/rfc2119>.                   
  830    [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS              
  831               Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,   
  832               <https://www.rfc-editor.org/info/rfc2181>.                   
  834    [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms    
  835               for DNS (EDNS(0))", STD 75, RFC 6891,                        
  836               DOI 10.17487/RFC6891, April 2013,                            
  837               <https://www.rfc-editor.org/info/rfc6891>.                   
  839    [RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and    
  840               D. Wessels, "DNS Transport over TCP - Implementation         
  841               Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,   
  842               <https://www.rfc-editor.org/info/rfc7766>.                   
  844    [RFC7828]  Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The   
  845               edns-tcp-keepalive EDNS0 Option", RFC 7828,                  
  846               DOI 10.17487/RFC7828, April 2016,                            
  847               <https://www.rfc-editor.org/info/rfc7828>.                   
  849    [RFC7873]  Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)   
  850               Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,          
  851               <https://www.rfc-editor.org/info/rfc7873>.                   
  853    [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC       
  854               2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,     
  855               May 2017, <https://www.rfc-editor.org/info/rfc8174>.         
  857 10.2.  Informative References                                              
  859    [accept_filter]                                                         
  860               FreeBSD, "FreeBSD accept_filter(9)", June 2000,              
  861               <https://www.freebsd.org/cgi/man.cgi?query=accept_filter>.   
  863    [APNIC]    Huston, G., "DNS XL", October 2020,                          
  864               <https://labs.apnic.net/?p=1380>.                            
  866    [AVOID_FRAGS]                                                           
  867               Fujiwara, K. and P. Vixie, "Fragmentation Avoidance in       
  868               DNS", Work in Progress, Internet-Draft, draft-ietf-dnsop-    
  869               avoid-fragmentation-06, 23 December 2021,                    
  870               <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-     
  871               avoid-fragmentation-06>.                                     
  873    [BIND]     Internet Systems Consortium, "BIND 9",                       
  874               <https://www.isc.org/bind/>.                                 
  876    [CASTRO2010]                                                            
  877               Castro, S., Zhang, M., John, W., Wessels, D., and K.         
  878               claffy, "Understanding and Preparing for DNS Evolution",     
  879               DOI 10.1007/978-3-642-12365-8_1, April 2010,                 
  880               <https://doi.org/10.1007/978-3-642-12365-8_1>.               
  882    [CHES94]   Cheswick, W. and S. Bellovin, "Firewalls and Internet        
  883               Security: Repelling the Wily Hacker", First Edition, 1994.   
  885    [CLOUDFLARE]                                                            
  886               Grant, D., "Economical With The Truth: Making DNSSEC         
  887               Answers Cheap", June 2016,                                   
  888               <https://blog.cloudflare.com/black-lies/>.                   
  890    [DAI21]    Dai, T., Shulman, H., and M. Waidner, "DNS-over-TCP          
  891               Considered Vulnerable", DOI 10.1145/3472305.3472884, July    
  892               2021, <https://doi.org/10.1145/3472305.3472884>.             
  894    [DESIGNTEAM]                                                            
  895               ICANN, "Root Zone KSK Rollover Plan", March 2016,            
  896               <https://www.iana.org/reports/2016/root-ksk-rollover-        
  897               design-20160307.pdf>.                                        
  899    [DJBDNS]   Bernstein, D., "When are TCP queries sent?", November        
  900               2002, <https://cr.yp.to/djbdns/tcp.html#why>.                
  902    [dnscap]   DNS-OARC, "DNSCAP", February 2014,                           
  903               <https://www.dns-oarc.net/tools/dnscap>.                     
  905    [dnstap]   "dnstap", <https://dnstap.info>.                             
  907    [ECDSA]    van Rijswijk-Deij, R., Sperotto, A., and A. Pras, "Making    
  908               the Case for Elliptic Curves in DNSSEC",                     
  909               DOI 10.1145/2831347.2831350, October 2015,                   
  910               <https://dl.acm.org/doi/10.1145/2831347.2831350>.            
  912    [FLAGDAY2020]                                                           
  913               DNS Software and Service Providers, "DNS Flag Day 2020",     
  914               October 2020, <https://dnsflagday.net/2020/>.                
  916    [FRAG_POISON]                                                           
  917               Herzberg, A. and H. Shulman, "Fragmentation Considered       
  918               Poisonous", May 2012,                                        
  919               <https://arxiv.org/pdf/1205.4011.pdf>.                       
  921    [HUSTON]   Huston, G., "Dealing with IPv6 fragmentation in the DNS",    
  922               August 2017, <https://blog.apnic.net/2017/08/22/dealing-     
  923               ipv6-fragmentation-dns/>.                                    
  925    [KSK_ROLLOVER_ARCHIVES]                                                 
  926               ICANN, "KSK Rollover List Archives", January 2019,           
  927               <https://mm.icann.org/pipermail/ksk-rollover/2019-January/   
  928               date.html>.                                                  
  930    [LEWIS]    Lewis, E., "2017 DNSSEC KSK Rollover", RIPE 74, May 2017,    
  931               <https://ripe74.ripe.net/presentations/25-RIPE74-lewis-      
  932               submission.pdf>.                                             
  934    [libpcap]  The Tcpdump Group, "Tcpdump and Libpcap",                    
  935               <https://www.tcpdump.org>.                                   
  937    [NETALYZR] Kreibich, C., Weaver, N., Nechaev, B., and V. Paxson,        
  938               "Netalyzr: Illuminating The Edge Network",                   
  939               DOI 10.1145/1879141.1879173, November 2010,                  
  940               <https://doi.org/10.1145/1879141.1879173>.                   
  942    [phrack]   horizon, "Defeating Sniffers and Intrusion Detection         
  943               Systems", Phrack Magazine, December 1998,                    
  944               <http://phrack.org/issues/54/10.html>.                       
  946    [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,        
  947               DOI 10.17487/RFC0768, August 1980,                           
  948               <https://www.rfc-editor.org/info/rfc768>.                    
  950    [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,          
  951               RFC 793, DOI 10.17487/RFC0793, September 1981,               
  952               <https://www.rfc-editor.org/info/rfc793>.                    
  954    [RFC0883]  Mockapetris, P., "Domain names: Implementation               
  955               specification", RFC 883, DOI 10.17487/RFC0883, November      
  956               1983, <https://www.rfc-editor.org/info/rfc883>.              
  958    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",   
  959               STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,       
  960               <https://www.rfc-editor.org/info/rfc1034>.                   
  962    [RFC1123]  Braden, R., Ed., "Requirements for Internet Hosts -          
  963               Application and Support", STD 3, RFC 1123,                   
  964               DOI 10.17487/RFC1123, October 1989,                          
  965               <https://www.rfc-editor.org/info/rfc1123>.                   
  967    [RFC1536]  Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.        
  968               Miller, "Common DNS Implementation Errors and Suggested      
  969               Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993,        
  970               <https://www.rfc-editor.org/info/rfc1536>.                   
  972    [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,      
  973               DOI 10.17487/RFC1995, August 1996,                           
  974               <https://www.rfc-editor.org/info/rfc1995>.                   
  976    [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone      
  977               Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,       
  978               August 1996, <https://www.rfc-editor.org/info/rfc1996>.      
  980    [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,      
  981               "Dynamic Updates in the Domain Name System (DNS UPDATE)",    
  982               RFC 2136, DOI 10.17487/RFC2136, April 1997,                  
  983               <https://www.rfc-editor.org/info/rfc2136>.                   
  985    [RFC2541]  Eastlake 3rd, D., "DNS Security Operational                  
  986               Considerations", RFC 2541, DOI 10.17487/RFC2541, March       
  987               1999, <https://www.rfc-editor.org/info/rfc2541>.             
  989    [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",           
  990               RFC 2671, DOI 10.17487/RFC2671, August 1999,                 
  991               <https://www.rfc-editor.org/info/rfc2671>.                   
  993    [RFC2694]  Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A.            
  994               Heffernan, "DNS extensions to Network Address Translators    
  995               (DNS_ALG)", RFC 2694, DOI 10.17487/RFC2694, September        
  996               1999, <https://www.rfc-editor.org/info/rfc2694>.             
  998    [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network        
  999               Address Translator (Traditional NAT)", RFC 3022,             
 1000               DOI 10.17487/RFC3022, January 2001,                          
 1001               <https://www.rfc-editor.org/info/rfc3022>.                   
 1003    [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC",         
 1004               RFC 3225, DOI 10.17487/RFC3225, December 2001,               
 1005               <https://www.rfc-editor.org/info/rfc3225>.                   
 1007    [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver   
 1008               message size requirements", RFC 3226,                        
 1009               DOI 10.17487/RFC3226, December 2001,                         
 1010               <https://www.rfc-editor.org/info/rfc3226>.                   
 1012    [RFC4472]  Durand, A., Ihren, J., and P. Savola, "Operational           
 1013               Considerations and Issues with IPv6 DNS", RFC 4472,          
 1014               DOI 10.17487/RFC4472, April 2006,                            
 1015               <https://www.rfc-editor.org/info/rfc4472>.                   
 1017    [RFC4953]  Touch, J., "Defending TCP Against Spoofing Attacks",         
 1018               RFC 4953, DOI 10.17487/RFC4953, July 2007,                   
 1019               <https://www.rfc-editor.org/info/rfc4953>.                   
 1021    [RFC4987]  Eddy, W., "TCP SYN Flooding Attacks and Common               
 1022               Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,   
 1023               <https://www.rfc-editor.org/info/rfc4987>.                   
 1025    [RFC5358]  Damas, J. and F. Neves, "Preventing Use of Recursive         
 1026               Nameservers in Reflector Attacks", BCP 140, RFC 5358,        
 1027               DOI 10.17487/RFC5358, October 2008,                          
 1028               <https://www.rfc-editor.org/info/rfc5358>.                   
 1030    [RFC5452]  Hubert, A. and R. van Mook, "Measures for Making DNS More    
 1031               Resilient against Forged Answers", RFC 5452,                 
 1032               DOI 10.17487/RFC5452, January 2009,                          
 1033               <https://www.rfc-editor.org/info/rfc5452>.                   
 1035    [RFC5507]  IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch,      
 1036               Ed., "Design Choices When Expanding the DNS", RFC 5507,      
 1037               DOI 10.17487/RFC5507, April 2009,                            
 1038               <https://www.rfc-editor.org/info/rfc5507>.                   
 1040    [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",           
 1041               BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,        
 1042               <https://www.rfc-editor.org/info/rfc5625>.                   
 1044    [RFC5927]  Gont, F., "ICMP Attacks against TCP", RFC 5927,              
 1045               DOI 10.17487/RFC5927, July 2010,                             
 1046               <https://www.rfc-editor.org/info/rfc5927>.                   
 1048    [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol    
 1049               (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,          
 1050               <https://www.rfc-editor.org/info/rfc5936>.                   
 1052    [RFC5961]  Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's     
 1053               Robustness to Blind In-Window Attacks", RFC 5961,            
 1054               DOI 10.17487/RFC5961, August 2010,                           
 1055               <https://www.rfc-editor.org/info/rfc5961>.                   
 1057    [RFC5966]  Bellis, R., "DNS Transport over TCP - Implementation         
 1058               Requirements", RFC 5966, DOI 10.17487/RFC5966, August        
 1059               2010, <https://www.rfc-editor.org/info/rfc5966>.             
 1061    [RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,             
 1062               "Computing TCP's Retransmission Timer", RFC 6298,            
 1063               DOI 10.17487/RFC6298, June 2011,                             
 1064               <https://www.rfc-editor.org/info/rfc6298>.                   
 1066    [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,     
 1067               DOI 10.17487/RFC6762, February 2013,                         
 1068               <https://www.rfc-editor.org/info/rfc6762>.                   
 1070    [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC             
 1071               Operational Practices, Version 2", RFC 6781,                 
 1072               DOI 10.17487/RFC6781, December 2012,                         
 1073               <https://www.rfc-editor.org/info/rfc6781>.                   
 1075    [RFC6950]  Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,     
 1076               "Architectural Considerations on Application Features in     
 1077               the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013,      
 1078               <https://www.rfc-editor.org/info/rfc6950>.                   
 1080    [RFC7413]  Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP     
 1081               Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,   
 1082               <https://www.rfc-editor.org/info/rfc7413>.                   
 1084    [RFC7477]  Hardaker, W., "Child-to-Parent Synchronization in DNS",      
 1085               RFC 7477, DOI 10.17487/RFC7477, March 2015,                  
 1086               <https://www.rfc-editor.org/info/rfc7477>.                   
 1088    [RFC7534]  Abley, J. and W. Sotomayor, "AS112 Nameserver Operations",   
 1089               RFC 7534, DOI 10.17487/RFC7534, May 2015,                    
 1090               <https://www.rfc-editor.org/info/rfc7534>.                   
 1092    [RFC7720]  Blanchet, M. and L-J. Liman, "DNS Root Name Service          
 1093               Protocol and Deployment Requirements", BCP 40, RFC 7720,     
 1094               DOI 10.17487/RFC7720, December 2015,                         
 1095               <https://www.rfc-editor.org/info/rfc7720>.                   
 1097    [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,     
 1098               and P. Hoffman, "Specification for DNS over Transport        
 1099               Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May   
 1100               2016, <https://www.rfc-editor.org/info/rfc7858>.             
 1102    [RFC7901]  Wouters, P., "CHAIN Query Requests in DNS", RFC 7901,        
 1103               DOI 10.17487/RFC7901, June 2016,                             
 1104               <https://www.rfc-editor.org/info/rfc7901>.                   
 1106    [RFC7918]  Langley, A., Modadugu, N., and B. Moeller, "Transport        
 1107               Layer Security (TLS) False Start", RFC 7918,                 
 1108               DOI 10.17487/RFC7918, August 2016,                           
 1109               <https://www.rfc-editor.org/info/rfc7918>.                   
 1111    [RFC8027]  Hardaker, W., Gudmundsson, O., and S. Krishnaswamy,          
 1112               "DNSSEC Roadblock Avoidance", BCP 207, RFC 8027,             
 1113               DOI 10.17487/RFC8027, November 2016,                         
 1114               <https://www.rfc-editor.org/info/rfc8027>.                   
 1116    [RFC8094]  Reddy, T., Wing, D., and P. Patil, "DNS over Datagram        
 1117               Transport Layer Security (DTLS)", RFC 8094,                  
 1118               DOI 10.17487/RFC8094, February 2017,                         
 1119               <https://www.rfc-editor.org/info/rfc8094>.                   
 1121    [RFC8162]  Hoffman, P. and J. Schlyter, "Using Secure DNS to            
 1122               Associate Certificates with Domain Names for S/MIME",        
 1123               RFC 8162, DOI 10.17487/RFC8162, May 2017,                    
 1124               <https://www.rfc-editor.org/info/rfc8162>.                   
 1126    [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6     
 1127               (IPv6) Specification", STD 86, RFC 8200,                     
 1128               DOI 10.17487/RFC8200, July 2017,                             
 1129               <https://www.rfc-editor.org/info/rfc8200>.                   
 1131    [RFC8324]  Klensin, J., "DNS Privacy, Authorization, Special Uses,      
 1132               Encoding, Characters, Matching, and Root Structure: Time     
 1133               for Another Look?", RFC 8324, DOI 10.17487/RFC8324,          
 1134               February 2018, <https://www.rfc-editor.org/info/rfc8324>.    
 1136    [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol   
 1137               Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,   
 1138               <https://www.rfc-editor.org/info/rfc8446>.                   
 1140    [RFC8467]  Mayrhofer, A., "Padding Policies for Extension Mechanisms    
 1141               for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,          
 1142               October 2018, <https://www.rfc-editor.org/info/rfc8467>.     
 1144    [RFC8482]  Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt,      
 1145               "Providing Minimal-Sized Responses to DNS Queries That       
 1146               Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January     
 1147               2019, <https://www.rfc-editor.org/info/rfc8482>.             
 1149    [RFC8483]  Song, L., Ed., Liu, D., Vixie, P., Kato, A., and S. Kerr,    
 1150               "Yeti DNS Testbed", RFC 8483, DOI 10.17487/RFC8483,          
 1151               October 2018, <https://www.rfc-editor.org/info/rfc8483>.     
 1153    [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS          
 1154               (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,        
 1155               <https://www.rfc-editor.org/info/rfc8484>.                   
 1157    [RFC8490]  Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,      
 1158               Lemon, T., and T. Pusateri, "DNS Stateful Operations",       
 1159               RFC 8490, DOI 10.17487/RFC8490, March 2019,                  
 1160               <https://www.rfc-editor.org/info/rfc8490>.                   
 1162    [RFC8501]  Howard, L., "Reverse DNS in IPv6 for Internet Service        
 1163               Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018,   
 1164               <https://www.rfc-editor.org/info/rfc8501>.                   
 1166    [RFC8806]  Kumari, W. and P. Hoffman, "Running a Root Server Local to   
 1167               a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,      
 1168               <https://www.rfc-editor.org/info/rfc8806>.                   
 1170    [RFC8906]  Andrews, M. and R. Bellis, "A Common Operational Problem     
 1171               in DNS Servers: Failure to Communicate", BCP 231,            
 1172               RFC 8906, DOI 10.17487/RFC8906, September 2020,              
 1173               <https://www.rfc-editor.org/info/rfc8906>.                   
 1175    [RFC8932]  Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and    
 1176               A. Mankin, "Recommendations for DNS Privacy Service          
 1177               Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932,         
 1178               October 2020, <https://www.rfc-editor.org/info/rfc8932>.     
 1180    [RFC8945]  Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,         
 1181               Gudmundsson, O., and B. Wellington, "Secret Key              
 1182               Transaction Authentication for DNS (TSIG)", STD 93,          
 1183               RFC 8945, DOI 10.17487/RFC8945, November 2020,               
 1184               <https://www.rfc-editor.org/info/rfc8945>.                   
 1186    [ROLL_YOUR_ROOT]                                                        
 1187               Müller, M., Thomas, M., Wessels, D., Hardaker, W., Chung,    
 1188               T., Toorop, W., and R. van Rijswijk-Deij, "Roll, Roll,       
 1189               Roll Your Root: A Comprehensive Analysis of the First Ever   
 1190               DNSSEC Root KSK Rollover", DOI 10.1145/3355369.3355570,      
 1191               October 2019,                                                
 1192               <https://dl.acm.org/doi/10.1145/3355369.3355570>.            
 1194    [RRL]      Vixie, P. and V. Schryver, "DNS Response Rate Limiting       
 1195               (DNS RRL)", ISC-TN-2012-1-Draft1, April 2012.                
 1197    [TDNS]     Zhu, L., Heidemann, J., Wessels, D., Mankin, A., and N.      
 1198               Somaiya, "Connection-Oriented DNS to Improve Privacy and     
 1199               Security", DOI 10.1109/SP.2015.18, May 2015,                 
 1200               <https://doi.org/10.1109/SP.2015.18>.                        
 1202    [TOYAMA]   Toyama, K., Ishibashi, K., Toyono, T., Ishino, M.,           
 1203               Yoshimura, C., and K. Fujiwara, "DNS Anomalies and Their     
 1204               Impacts on DNS Cache Servers", NANOG 32, October 2004.       
 1206    [VERISIGN] Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in    
 1207               Root Server DITL Data", DNS-OARC 2014 Fall Workshop,         
 1208               October 2014.                                                
 1210    [WIKIPEDIA_TFO]                                                         
 1211               Wikipedia, "TCP Fast Open", February 2022,                   
 1212               <https://en.wikipedia.org/w/                                 
 1213               index.php?title=TCP_Fast_Open&oldid=1071397204>.             
 1215 Appendix A.  RFCs Related to DNS Transport over TCP                        
 1217    This section enumerates all known RFCs with a status of Internet        
 1218    Standard, Proposed Standard, Informational, Best Current Practice, or   
 1219    Experimental that either implicitly or explicitly make assumptions or   
 1220    statements about the use of TCP as a transport for the DNS germane to   
 1221    this document.                                                          
 1225    The Internet Standard [RFC1035] is the base DNS specification that      
 1226    explicitly defines support for DNS over TCP.                            
 1228 A.2.  RFC 1536 - Common DNS Implementation Errors and Suggested Fixes      
 1230    The Informational document [RFC1536] states that UDP is "the chosen     
 1231    protocol for communication though TCP is used for zone transfers."      
 1232    That statement should now be considered in its historical context and   
 1233    is no longer a proper reflection of modern expectations.                
 1235 A.3.  RFC 1995 - Incremental Zone Transfer in DNS                          
 1237    The Proposed Standard [RFC1995] documents the use of TCP as the         
 1238    fallback transport when Incremental Zone Transfer (IXFR) responses do   
 1239    not fit into a single UDP response.  As with Authoritative Transfer     
 1240    (AXFR), IXFR messages are typically delivered over TCP by default in    
 1241    practice.                                                               
 1243 A.4.  RFC 1996 - A Mechanism for Prompt Notification of Zone Changes       
 1244       (DNS NOTIFY)                                                         
 1246    The Proposed Standard [RFC1996] suggests that a primary server may      
 1247    decide to issue NOTIFY messages over TCP.  In practice, NOTIFY          
 1248    messages are generally sent over UDP, but this specification leaves     
 1249    open the possibility that the choice of transport protocol is up to     
 1250    the primary server; therefore, a secondary server ought to be able to   
 1251    operate over both UDP and TCP.                                          
 1253 A.5.  RFC 2181 - Clarifications to the DNS Specification                   
 1255    The Proposed Standard [RFC2181] includes clarifying text on how a       
 1256    client should react to the TC bit set on responses.  It is advised      
 1257    that the response be discarded and the query resent using TCP.          
 1259 A.6.  RFC 2694 - DNS extensions to Network Address Translators (DNS_ALG)   
 1261    The Informational document [RFC2694] enumerates considerations for      
 1262    NAT devices to properly handle DNS traffic.  This document is           
 1263    noteworthy in its suggestion that "[t]ypically, TCP is used for AXFR    
 1264    requests," as further evidence that helps explain why DNS over TCP      
 1265    may have often been treated very differently than DNS over UDP in       
 1266    operational networks.                                                   
 1268 A.7.  RFC 3225 - Indicating Resolver Support of DNSSEC                     
 1270    The Proposed Standard [RFC3225] makes statements indicating that DNS    
 1271    over TCP is "detrimental" as a result of increased traffic, latency,    
 1272    and server load.  This document is a companion to the next document     
 1273    in the RFC Series that describes the requirement for EDNS(0) support    
 1274    for DNSSEC.                                                             
 1276 A.8.  RFC 3226 - DNSSEC and IPv6 A6 aware server/resolver message size     
 1277       requirements                                                         
 1279    Although updated by later DNSSEC RFCs, the Proposed Standard            
 1280    [RFC3226] strongly argues in favor of UDP messages instead of TCP,      
 1281    largely for performance reasons.  The document declares EDNS(0) a       
 1282    requirement for DNSSEC servers and advocates that packet                
 1283    fragmentation may be preferable to TCP in certain situations.           
 1285 A.9.  RFC 4472 - Operational Considerations and Issues with IPv6 DNS       
 1287    The Informational document [RFC4472] notes that IPv6 data may           
 1288    increase DNS responses beyond what would fit in a UDP message.  What    
 1289    is particularly noteworthy, but perhaps less common today than when     
 1290    this document was written, is that it refers to implementations that    
 1291    truncate data without setting the TC bit to encourage the client to     
 1292    resend the query using TCP.                                             
 1294 A.10.  RFC 5452 - Measures for Making DNS More Resilient against Forged    
 1295        Answers                                                             
 1297    The Proposed Standard [RFC5452] arose as public DNS systems began to    
 1298    experience widespread abuse from spoofed queries, resulting in          
 1299    amplification and reflection attacks against unwitting victims.  One    
 1300    of the leading justifications for supporting DNS over TCP to thwart     
 1301    these attacks is briefly described in Section 9.3 of [RFC5452]          
 1302    ("Spoof Detection and Countermeasure").                                 
 1304 A.11.  RFC 5507 - Design Choices When Expanding the DNS                    
 1306    The Informational document [RFC5507] was largely an attempt to          
 1307    dissuade new DNS data types from overloading the TXT resource record    
 1308    type.  In so doing, it summarizes the conventional wisdom of DNS        
 1309    design and implementation practices.  The authors suggest TCP           
 1310    overhead and stateful properties pose challenges compared to UDP and    
 1311    imply that UDP is generally preferred for performance and robustness.   
 1313 A.12.  RFC 5625 - DNS Proxy Implementation Guidelines                      
 1315    The Best Current Practice document [RFC5625] provides DNS proxy         
 1316    implementation guidance including the mandate that a proxy "MUST        
 1317    [...] be prepared to receive and forward queries over TCP" even         
 1318    though it suggests that, historically, TCP transport has not been       
 1319    strictly mandatory in stub resolvers or recursive servers.              
 1321 A.13.  RFC 5936 - DNS Zone Transfer Protocol (AXFR)                        
 1323    The Proposed Standard [RFC5936] provides a detailed specification for   
 1324    the zone transfer protocol, as originally outlined in the early DNS     
 1325    standards.  AXFR operation is limited to TCP and not specified for      
 1326    UDP.  This document discusses TCP usage at length.                      
 1328 A.14.  RFC 7534 - AS112 Nameserver Operations                              
 1330    The Informational document [RFC7534] enumerates the requirements for    
 1331    operation of AS112 project DNS servers.  New AS112 nodes are tested     
 1332    for their ability to provide service on both UDP and TCP transports,    
 1333    with the implication that TCP service is an expected part of normal     
 1334    operations.                                                             
 1336 A.15.  RFC 6762 - Multicast DNS                                            
 1338    In the Proposed Standard [RFC6762], the TC bit is deemed to have        
 1339    essentially the same meaning as described in the original DNS           
 1340    specifications.  That is, if a response with the TC bit set is          
 1341    received, "[...] the querier SHOULD reissue its query using TCP in      
 1342    order to receive the larger response."                                  
 1344 A.16.  RFC 6891 - Extension Mechanisms for DNS (EDNS(0))                   
 1346    The Internet Standard [RFC6891] helped slow the use of and need for     
 1347    DNS-over-TCP messages.  This document highlights concerns over server   
 1348    load and scalability in widespread use of DNS over TCP.                 
 1350 A.17.  IAB RFC 6950 - Architectural Considerations on Application          
 1351        Features in the DNS                                                 
 1353    The Informational document [RFC6950] draws attention to large data in   
 1354    the DNS.  TCP is referenced in the context as a common fallback         
 1355    mechanism and counter to some spoofing attacks.                         
 1357 A.18.  RFC 7477 - Child-to-Parent Synchronization in DNS                   
 1359    The Proposed Standard [RFC7477] specifies an RRType and a protocol to   
 1360    signal and synchronize NS, A, and AAAA resource record changes from a   
 1361    child-to-parent zone.  Since this protocol may require multiple         
 1362    requests and responses, it recommends utilizing DNS over TCP to         
 1363    ensure the conversation takes place between a consistent pair of end    
 1364    nodes.                                                                  
 1366 A.19.  RFC 7720 - DNS Root Name Service Protocol and Deployment            
 1367        Requirements                                                        
 1369    The Best Current Practice document [RFC7720] declares that root name    
 1370    service "MUST support UDP [RFC0768] and TCP [RFC0793] transport of      
 1371    DNS queries and responses."                                             
 1373 A.20.  RFC 7766 - DNS Transport over TCP - Implementation Requirements     
 1375    The Proposed Standard [RFC7766] instructs DNS implementors to provide   
 1376    support for carrying DNS-over-TCP messages in their software and        
 1377    might be considered the direct ancestor of this operational             
 1378    requirements document.  The implementation requirements document        
 1379    codifies mandatory support for DNS-over-TCP in compliant DNS software   
 1380    but makes no recommendations to operators, which we seek to address     
 1381    here.                                                                   
 1383 A.21.  RFC 7828 - The edns-tcp-keepalive EDNS(0) Option                    
 1385    The Proposed Standard [RFC7828] defines an EDNS(0) option to            
 1386    negotiate an idle timeout value for long-lived DNS-over-TCP             
 1387    connections.  Consequently, this document is only applicable and        
 1388    relevant to DNS-over-TCP sessions and between implementations that      
 1389    support this option.                                                    
 1391 A.22.  RFC 7858 - Specification for DNS over Transport Layer Security      
 1392        (TLS)                                                               
 1394    The Proposed Standard [RFC7858] defines a method for putting DNS        
 1395    messages into a TCP-based encrypted channel using TLS.  This            
 1396    specification is noteworthy for explicitly targeting the stub-to-       
 1397    recursive traffic but does not preclude its application from            
 1398    recursive-to-authoritative traffic.                                     
 1400 A.23.  RFC 7873 - Domain Name System (DNS) Cookies                         
 1402    The Proposed Standard [RFC7873] describes an EDNS(0) option to          
 1403    provide additional protection against query and answer forgery.  This   
 1404    specification mentions DNS over TCP as an alternative mechanism when    
 1405    DNS cookies are not available.  The specification does make mention     
 1406    of DNS-over-TCP processing in two specific situations.  In one, when    
 1407    a server receives only a client cookie in a request, the server         
 1408    should consider whether the request arrived over TCP, and if so, it     
 1409    should consider accepting TCP as sufficient to authenticate the         
 1410    request and respond accordingly.  In another, when a client receives    
 1411    a BADCOOKIE reply using a fresh server cookie, the client should        
 1412    retry using TCP as the transport.                                       
 1414 A.24.  RFC 7901 - CHAIN Query Requests in DNS                              
 1416    The Experimental specification [RFC7901] describes an EDNS(0) option    
 1417    that can be used by a security-aware validating resolver to request     
 1418    and obtain a complete DNSSEC validation path for any single query.      
 1419    This document requires the use of DNS over TCP or a transport           
 1420    mechanism verified by a source IP address such as EDNS-COOKIE           
 1421    [RFC7873].                                                              
 1423 A.25.  RFC 8027 - DNSSEC Roadblock Avoidance                               
 1425    The Best Current Practice document [RFC8027] details observed           
 1426    problems with DNSSEC deployment and mitigation techniques.  Network     
 1427    traffic blocking and restrictions, including DNS-over-TCP messages,     
 1428    are highlighted as one reason for DNSSEC deployment issues.  While      
 1429    this document suggests these sorts of problems are due to "non-         
 1430    compliant infrastructure", the scope of the document is limited to      
 1431    detection and mitigation techniques to avoid so-called DNSSEC           
 1432    roadblocks.                                                             
 1434 A.26.  RFC 8094 - DNS over Datagram Transport Layer Security (DTLS)        
 1436    The Experimental specification [RFC8094] details a protocol that uses   
 1437    a datagram transport (UDP) but stipulates that "DNS clients and         
 1438    servers that implement DNS over DTLS MUST also implement DNS over TLS   
 1439    in order to provide privacy for clients that desire Strict Privacy      
 1440    [...]."  This requirement implies DNS over TCP must be supported in     
 1441    case the message size is larger than the path MTU.                      
 1443 A.27.  RFC 8162 - Using Secure DNS to Associate Certificates with Domain   
 1444        Names for S/MIME                                                    
 1446    The Experimental specification [RFC8162] describes a technique to       
 1447    authenticate user X.509 certificates in an S/MIME system via the DNS.   
 1448    The document points out that the new experimental resource record       
 1449    types are expected to carry large payloads, resulting in the            
 1450    suggestion that "applications SHOULD use TCP -- not UDP -- to perform   
 1451    queries for the SMIMEA resource record."                                
 1453 A.28.  RFC 8324 - DNS Privacy, Authorization, Special Uses, Encoding,      
 1454        Characters, Matching, and Root Structure: Time for Another Look?    
 1456    The Informational document [RFC8324] briefly discusses the common       
 1457    role and challenges of DNS over TCP throughout the history of DNS.      
 1459 A.29.  RFC 8467 - Padding Policies for Extension Mechanisms for DNS        
 1460        (EDNS(0))                                                           
 1462    The Experimental document [RFC8467] reminds implementors to consider    
 1463    the underlying transport protocol (e.g., TCP) when calculating the      
 1464    padding length when artificially increasing the DNS message size with   
 1465    an EDNS(0) padding option.                                              
 1467 A.30.  RFC 8482 - Providing Minimal-Sized Responses to DNS Queries That    
 1468        Have QTYPE=ANY                                                      
 1470    The Proposed Standard [RFC8482] describes alternative ways that DNS     
 1471    servers can respond to queries of type ANY, which are sometimes used    
 1472    to provide amplification in DDoS attacks.  The specification notes      
 1473    that responders may behave differently, depending on the transport.     
 1474    For example, minimal-sized responses may be used over UDP transport,    
 1475    while full responses may be given over TCP.                             
 1477 A.31.  RFC 8483 - Yeti DNS Testbed                                         
 1479    The Informational document [RFC8483] describes a testbed environment    
 1480    that highlights some DNS-over-TCP behaviors, including issues           
 1481    involving packet fragmentation and operational requirements for TCP     
 1482    stream assembly in order to conduct DNS measurement and analysis.       
 1484 A.32.  RFC 8484 - DNS Queries over HTTPS (DoH)                             
 1486    The Proposed Standard [RFC8484] defines a protocol for sending DNS      
 1487    queries and responses over HTTPS.  This specification assumes TLS and   
 1488    TCP for the underlying security and transport layers, respectively.     
 1489    Self-described as a technique that more closely resembles a tunneling   
 1490    mechanism, DoH nevertheless likely implies DNS over TCP in some         
 1491    sense, if not directly.                                                 
 1493 A.33.  RFC 8490 - DNS Stateful Operations                                  
 1495    The Proposed Standard [RFC8490] updates the base protocol               
 1496    specification with a new OPCODE to help manage stateful operations in   
 1497    persistent sessions, such as those that might be used by DNS over       
 1498    TCP.                                                                    
 1500 A.34.  RFC 8501 - Reverse DNS in IPv6 for Internet Service Providers       
 1502    The Informational document [RFC8501] identifies potential operational   
 1503    challenges with dynamic DNS, including denial-of-service threats.       
 1504    The document suggests TCP may provide some advantages but that          
 1505    updating hosts would need to be explicitly configured to use TCP        
 1506    instead of UDP.                                                         
 1508 A.35.  RFC 8806 - Running a Root Server Local to a Resolver                
 1510    The Informational document [RFC8806] describes how to obtain and        
 1511    operate a local copy of the root zone with examples showing how to      
 1512    pull from authoritative sources using a DNS-over-TCP zone transfer.     
 1514 A.36.  RFC 8906 - A Common Operational Problem in DNS Servers: Failure     
 1515        to Communicate                                                      
 1517    The Best Current Practice document [RFC8906] discusses a number of      
 1518    DNS operational failure scenarios and how to avoid them.  This          
 1519    includes discussions involving DNS-over-TCP queries, EDNS over TCP,     
 1520    and a testing methodology that includes a section on verifying DNS-     
 1521    over-TCP functionality.                                                 
 1523 A.37.  RFC 8932 - Recommendations for DNS Privacy Service Operators        
 1525    The Best Current Practice document [RFC8932] presents privacy           
 1526    considerations to DNS privacy service operators.  These mechanisms      
 1527    sometimes include the use of TCP and are therefore susceptible to       
 1528    information leakage such as TCP-based fingerprinting.  This document    
 1529    also references an earlier draft version of this document.              
 1531 A.38.  RFC 8945 - Secret Key Transaction Authentication for DNS (TSIG)     
 1533    The Internet Standard [RFC8945] recommends that a client use TCP if     
 1534    truncated TSIG messages are received.                                   
 1536 Acknowledgments                                                            
 1538    This document was initially motivated by feedback from students who     
 1539    pointed out that they were hearing contradictory information about      
 1540    filtering DNS-over-TCP messages.  Thanks in particular to a teaching    
 1541    colleague, JPL, who perhaps unknowingly encouraged the initial          
 1542    research into the differences between what the community has            
 1543    historically said and did.  Thanks to all the NANOG 63 attendees who    
 1544    provided feedback for an early talk on this subject.                    
 1546    The following individuals provided an array of feedback to help         
 1547    improve this document: Joe Abley, Piet Barber, Sara Dickinson, Tony     
 1548    Finch, Bob Harold, Paul Hoffman, Geoff Huston, Tatuya Jinmei, Puneet    
 1549    Sood, and Richard Wilhelm.  The authors are also indebted to the        
 1550    contributions stemming from discussion in the TCPM Working Group        
 1551    meeting at IETF 104.  Any remaining errors or imperfections are the     
 1552    sole responsibility of the document authors.                            
 1554 Authors' Addresses                                                         
 1556    John Kristoff                                                           
 1557    Dataplane.org                                                           
 1558    Chicago, IL 60605                                                       
 1559    United States of America                                                
 1560    Phone: +1 312 493 0305                                                  
 1561    Email: jtk@dataplane.org                                                
 1562    URI:   https://dataplane.org/jtk/                                       
 1565    Duane Wessels                                                           
 1566    Verisign                                                                
 1567    12061 Bluemont Way                                                      
 1568    Reston, VA 20190                                                        
 1569    United States of America                                                
 1570    Phone: +1 703 948 3200                                                  
 1571    Email: dwessels@verisign.com                                            
 1572    URI:   https://verisign.com                                             

The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.

This RFC is included in the DNS RFCs annotation project whose home page is here.