1 Internet Engineering Task Force (IETF)                        P. Wouters   
    2 Request for Comments: 7828                                       Red Hat   
    3 Category: Standards Track                                       J. Abley   
    4 ISSN: 2070-1721                                                Dyn, Inc.   
    5                                                             S. Dickinson   
    6                                                                  Sinodun   
    7                                                                R. Bellis   
    8                                                                      ISC   
    9                                                               April 2016   
   10                                                                            
   11                                                                            
   12                   The edns-tcp-keepalive EDNS0 Option                      
   13                                                                            
   14 Abstract                                                                   
   15                                                                            
   16    DNS messages between clients and servers may be received over either    
   17    UDP or TCP.  UDP transport involves keeping less state on a busy        
   18    server, but can cause truncation and retries over TCP.  Additionally,   
   19    UDP can be exploited for reflection attacks.  Using TCP would reduce    
   20    retransmits and amplification.  However, clients commonly use TCP       
   21    only for retries and servers typically use idle timeouts on the order   
   22    of seconds.                                                             
   23                                                                            
   24    This document defines an EDNS0 option ("edns-tcp-keepalive") that       
   25    allows DNS servers to signal a variable idle timeout.  This             
   26    signalling encourages the use of long-lived TCP connections by          
   27    allowing the state associated with TCP transport to be managed          
   28    effectively with minimal impact on the DNS transaction time.            
   29                                                                            
   30 Status of This Memo                                                        
   31                                                                            
   32    This is an Internet Standards Track document.                           
   33                                                                            
   34    This document is a product of the Internet Engineering Task Force       
   35    (IETF).  It represents the consensus of the IETF community.  It has     
   36    received public review and has been approved for publication by the     
   37    Internet Engineering Steering Group (IESG).  Further information on     
   38    Internet Standards is available in Section 2 of RFC 5741.               
   39                                                                            
   40    Information about the current status of this document, any errata,      
   41    and how to provide feedback on it may be obtained at                    
   42    http://www.rfc-editor.org/info/rfc7828.                                 
   43                                                                            
   44                                                                            
   45                                                                            
   46                                                                            
   47                                                                            
   48                                                                            
   49                                                                            
   50                                                                            
   51                                                                            
   52 Wouters, et al.              Standards Track                    [Page 1]   

   53 RFC 7828           The edns-tcp-keepalive EDNS0 Option        April 2016   
   54                                                                            
   55                                                                            
   56 Copyright Notice                                                           
   57                                                                            
   58    Copyright (c) 2016 IETF Trust and the persons identified as the         
   59    document authors.  All rights reserved.                                 
   60                                                                            
   61    This document is subject to BCP 78 and the IETF Trust's Legal           
   62    Provisions Relating to IETF Documents                                   
   63    (http://trustee.ietf.org/license-info) in effect on the date of         
   64    publication of this document.  Please review these documents            
   65    carefully, as they describe your rights and restrictions with respect   
   66    to this document.  Code Components extracted from this document must    
   67    include Simplified BSD License text as described in Section 4.e of      
   68    the Trust Legal Provisions and are provided without warranty as         
   69    described in the Simplified BSD License.                                
   70                                                                            
   71 Table of Contents                                                          
   72                                                                            
   73    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3   
   74    2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   4   
   75    3.  The edns-tcp-keepalive Option . . . . . . . . . . . . . . . .   5   
   76      3.1.  Option Format . . . . . . . . . . . . . . . . . . . . . .   5   
   77      3.2.  Use by DNS Clients  . . . . . . . . . . . . . . . . . . .   5   
   78        3.2.1.  Sending Queries . . . . . . . . . . . . . . . . . . .   5   
   79        3.2.2.  Receiving Responses . . . . . . . . . . . . . . . . .   6   
   80      3.3.  Use by DNS Servers  . . . . . . . . . . . . . . . . . . .   6   
   81        3.3.1.  Receiving Queries . . . . . . . . . . . . . . . . . .   6   
   82        3.3.2.  Sending Responses . . . . . . . . . . . . . . . . . .   6   
   83      3.4.  TCP Session Management  . . . . . . . . . . . . . . . . .   7   
   84      3.5.  Non-clean Paths . . . . . . . . . . . . . . . . . . . . .   8   
   85      3.6.  Anycast Considerations  . . . . . . . . . . . . . . . . .   8   
   86    4.  Intermediary Considerations . . . . . . . . . . . . . . . . .   8   
   87    5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9   
   88    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9   
   89    7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9   
   90      7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9   
   91      7.2.  Informative References  . . . . . . . . . . . . . . . . .  10   
   92    Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11   
   93    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11   
   94                                                                            
   95                                                                            
   96                                                                            
   97                                                                            
   98                                                                            
   99                                                                            
  100                                                                            
  101                                                                            
  102                                                                            
  103                                                                            
  104                                                                            
  105                                                                            
  106                                                                            
  107 Wouters, et al.              Standards Track                    [Page 2]   

  108 RFC 7828           The edns-tcp-keepalive EDNS0 Option        April 2016   
  109                                                                            
  110                                                                            
  111 1.  Introduction                                                           
  112                                                                            
  113    DNS messages between clients and servers may be received over either    
  114    UDP or TCP [RFC1035].  Historically, DNS clients used APIs that only    
  115    facilitated sending and receiving a single query over either UDP or     
  116    TCP.  New APIs and deployment of DNSSEC validating resolvers on hosts   
  117    that in the past were using stub resolving only is increasing the DNS   
  118    client base that prefer using long-lived TCP connections.  Long-lived   
  119    TCP connections can result in lower request latency than the case       
  120    where UDP transport is used and truncated responses are received.       
  121    This is because clients that retry over TCP following a truncated UDP   
  122    response typically only use the TCP session for a single (request,      
  123    response) pair, continuing with UDP transport for subsequent queries.   
  124                                                                            
  125    The use of TCP transport requires state to be retained on DNS           
  126    servers.  If a server is to perform adequately with a significant       
  127    query load received over TCP, it must manage its available resources    
  128    to ensure that all established TCP sessions are well-used, and idle     
  129    connections are closed after an appropriate amount of time.             
  130                                                                            
  131    UDP transport is stateless, and hence presents a much lower resource    
  132    burden on a busy DNS server than TCP.  An exchange of DNS messages      
  133    over UDP can also be completed in a single round trip between           
  134    communicating hosts, resulting in optimally short transaction times.    
  135    UDP transport is not without its risks, however.                        
  136                                                                            
  137    A single-datagram exchange over UDP between two hosts can be            
  138    exploited to enable a reflection attack on a third party.  Response     
  139    Rate Limiting [RRL] is designed to help mitigate such attacks against   
  140    authoritative-only servers.  One feature of RRL is to let some amount   
  141    of responses "slip" through the rate limiter.  These are returned       
  142    with the TC (truncation) bit set, which causes legitimate clients to    
  143    resend the same query using TCP transport.                              
  144                                                                            
  145    [RFC1035] specified a maximum DNS message size over UDP transport of    
  146    512 bytes.  Deployment of DNSSEC [RFC4033] and other protocols          
  147    subsequently increased the observed frequency at which responses        
  148    exceed this limit.  EDNS0 [RFC6891] allows DNS messages larger than     
  149    512 bytes to be exchanged over UDP, with a corresponding increased      
  150    incidence of fragmentation.  Fragmentation is known to be problematic   
  151    in general, and has also been implicated in increasing the risk of      
  152    cache poisoning attacks [fragmentation-considered-poisonous].           
  153                                                                            
  154    TCP transport is less susceptible to the risks of fragmentation and     
  155    reflection attacks.  However, TCP transport for DNS as currently        
  156    deployed has expensive setup overhead, compared to using UDP (when no   
  157    retry is required).                                                     
  158                                                                            
  159                                                                            
  160                                                                            
  161                                                                            
  162 Wouters, et al.              Standards Track                    [Page 3]   

  163 RFC 7828           The edns-tcp-keepalive EDNS0 Option        April 2016   
  164                                                                            
  165                                                                            
  166    The overhead of the three-way TCP handshake for a single DNS            
  167    transaction is substantial, increasing the transaction time for a       
  168    single (request, response) pair of DNS messages from 1x RTT to 2x       
  169    RTT.  There is no such overhead for a session that is already           
  170    established; therefore, the overhead of the initial TCP handshake is    
  171    minimised when the resulting session is used to exchange multiple DNS   
  172    message pairs over a single session.  The extra RTT time for session    
  173    setup can be represented as the equation (1 + N)/N, where N             
  174    represents the number of DNS message pairs that utilize the session     
  175    and the result approaches unity as N increases.                         
  176                                                                            
  177    With increased deployment of DNSSEC and new RR types containing         
  178    application-specific cryptographic material, there is an increase in    
  179    the prevalence of truncated responses received over UDP with retries    
  180    over TCP.  The overhead for a DNS transaction over UDP truncated due    
  181    to RRL is 3x RTT higher than the overhead imposed on the same           
  182    transaction initiated over TCP.                                         
  183                                                                            
  184    This document proposes a signalling mechanism between DNS clients and   
  185    servers that encourages the use of long-lived TCP connections by        
  186    allowing the state associated with TCP transport to be managed          
  187    effectively with minimal impact on the DNS transaction time.            
  188                                                                            
  189    This mechanism will be of benefit for both stub-resolver and            
  190    resolver-authoritative TCP connections.  In the latter case, the        
  191    persistent nature of the TCP connection can provide improved defence    
  192    against attacks including DDoS.                                         
  193                                                                            
  194    The reduced overhead of this extension adds up significantly when       
  195    combined with other EDNS0 extensions, such as [CHAIN-QUERY] and         
  196    [DNS-over-TLS].  For example, the combination of these EDNS0            
  197    extensions make it possible for hosts on high-latency mobile networks   
  198    to natively and efficiently perform DNSSEC validation and encrypt       
  199    queries.                                                                
  200                                                                            
  201 2.  Requirements Notation                                                  
  202                                                                            
  203    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  204    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this    
  205    document are to be interpreted as described in [RFC2119].               
  206                                                                            
  207                                                                            
  208                                                                            
  209                                                                            
  210                                                                            
  211                                                                            
  212                                                                            
  213                                                                            
  214                                                                            
  215                                                                            
  216                                                                            
  217 Wouters, et al.              Standards Track                    [Page 4]   

  218 RFC 7828           The edns-tcp-keepalive EDNS0 Option        April 2016   
  219                                                                            
  220                                                                            
  221 3.  The edns-tcp-keepalive Option                                          
  222                                                                            
  223    This document specifies a new EDNS0 [RFC6891] option, edns-tcp-         
  224    keepalive, which can be used by DNS clients and servers to signal a     
  225    willingness to keep an idle TCP session open to conduct future DNS      
  226    transactions, with the idle timeout being specified by the server.      
  227    This specification does not distinguish between different types of      
  228    DNS client and server in the use of this option.                        
  229                                                                            
  230    [RFC7766] defines an 'idle DNS-over-TCP session' from both the client   
  231    and server perspective.  The idle timeout described here begins when    
  232    the idle condition is met per that definition and should be reset       
  233    when that condition is lifted, i.e., when a client sends a message or   
  234    when a server receives a message on an idle connection.                 
  235                                                                            
  236 3.1.  Option Format                                                        
  237                                                                            
  238    The edns-tcp-keepalive option is encoded as follows:                    
  239                                                                            
  240                         1                   2                   3          
  241     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1        
  242    +-------------------------------+-------------------------------+       
  243    !         OPTION-CODE           !         OPTION-LENGTH         !       
  244    +-------------------------------+-------------------------------+       
  245    |           TIMEOUT             !                                       
  246    +-------------------------------+                                       
  247                                                                            
  248    where:                                                                  
  249                                                                            
  250    OPTION-CODE:   the EDNS0 option code assigned to edns-tcp-keepalive,    
  251       11                                                                   
  252                                                                            
  253    OPTION-LENGTH:   the value 0 if the TIMEOUT is omitted, the value 2     
  254       if it is present;                                                    
  255                                                                            
  256    TIMEOUT:   an idle timeout value for the TCP connection, specified in   
  257       units of 100 milliseconds, encoded in network byte order.            
  258                                                                            
  259 3.2.  Use by DNS Clients                                                   
  260                                                                            
  261 3.2.1.  Sending Queries                                                    
  262                                                                            
  263    DNS clients MUST NOT include the edns-tcp-keepalive option in queries   
  264    sent using UDP transport.                                               
  265                                                                            
  266    DNS clients MAY include the edns-tcp-keepalive option in the first      
  267    query sent to a server using TCP transport to signal their desire to    
  268    keep the connection open when idle.                                     
  269                                                                            
  270                                                                            
  271                                                                            
  272 Wouters, et al.              Standards Track                    [Page 5]   

  273 RFC 7828           The edns-tcp-keepalive EDNS0 Option        April 2016   
  274                                                                            
  275                                                                            
  276    DNS clients MAY include the edns-tcp-keepalive option in subsequent     
  277    queries sent to a server using TCP transport to signal their            
  278    continued desire to keep the connection open when idle.                 
  279                                                                            
  280    Clients MUST specify an OPTION-LENGTH of 0 and omit the TIMEOUT         
  281    value.                                                                  
  282                                                                            
  283 3.2.2.  Receiving Responses                                                
  284                                                                            
  285    A DNS client that receives a response using UDP transport that          
  286    includes the edns-tcp-keepalive option MUST ignore the option.          
  287                                                                            
  288    A DNS client that receives a response using TCP transport that          
  289    includes the edns-tcp-keepalive option MAY keep the existing TCP        
  290    session open when it is idle.  It SHOULD honour the timeout received    
  291    in that response (overriding any previous timeout) and initiate close   
  292    of the connection before the timeout expires.                           
  293                                                                            
  294    A DNS client that receives a response that includes the edns-tcp-       
  295    keepalive option with a TIMEOUT value of 0 SHOULD send no more          
  296    queries on that connection and initiate closing the connection as       
  297    soon as it has received all outstanding responses.                      
  298                                                                            
  299    A DNS client that sent a query containing the edns-keepalive-option     
  300    but receives a response that does not contain the edns-keepalive-       
  301    option SHOULD assume the server does not support keepalive and behave   
  302    following the guidance in [RFC7766].  This holds true even if a         
  303    previous edns-keepalive-option exchange occurred on the existing TCP    
  304    connection.                                                             
  305                                                                            
  306 3.3.  Use by DNS Servers                                                   
  307                                                                            
  308 3.3.1.  Receiving Queries                                                  
  309                                                                            
  310    A DNS server that receives a query using UDP transport that includes    
  311    the edns-tcp-keepalive option MUST ignore the option.                   
  312                                                                            
  313    A DNS server that receives a query using TCP transport that includes    
  314    the edns-tcp-keepalive option MAY modify the local idle timeout         
  315    associated with that TCP session if resources permit.                   
  316                                                                            
  317 3.3.2.  Sending Responses                                                  
  318                                                                            
  319    A DNS server that receives a query sent using TCP transport that        
  320    includes an OPT RR (with or without the edns-tcp-keepalive option)      
  321    MAY include the edns-tcp-keepalive option in the response to signal     
  322    the expected idle timeout on a connection.  Servers MUST specify the    
  323    TIMEOUT value that is currently associated with the TCP session.  It    
  324                                                                            
  325                                                                            
  326                                                                            
  327 Wouters, et al.              Standards Track                    [Page 6]   

  328 RFC 7828           The edns-tcp-keepalive EDNS0 Option        April 2016   
  329                                                                            
  330                                                                            
  331    is reasonable for this value to change according to local resource      
  332    constraints.  The DNS server SHOULD send an edns-tcp-keepalive option   
  333    with a timeout of 0 if it deems its local resources are too low to      
  334    service more TCP keepalive sessions or if it wants clients to close     
  335    currently open connections.                                             
  336                                                                            
  337 3.4.  TCP Session Management                                               
  338                                                                            
  339    Both DNS clients and servers are subject to resource constraints that   
  340    will limit the extent to which TCP sessions can persist.  Effective     
  341    limits for the number of active sessions that can be maintained on      
  342    individual clients and servers should be established, either as         
  343    configuration options or by interrogation of process limits imposed     
  344    by the operating system.  Servers that implement edns-tcp-keepalive     
  345    should also engage in TCP connection management by recycling existing   
  346    connections when appropriate, closing connections gracefully, and       
  347    managing request queues to enable fair use.                             
  348                                                                            
  349    In the event that there is greater demand for TCP sessions than can     
  350    be accommodated, servers may reduce the TIMEOUT value signalled in      
  351    successive DNS messages to minimise idle time on existing sessions.     
  352    This also allows, for example, clients with other candidate servers     
  353    to query to establish new TCP sessions with different servers in        
  354    expectation that an existing session is likely to be closed or to       
  355    fall back to UDP.                                                       
  356                                                                            
  357    Based on TCP session resources, servers may signal a TIMEOUT value of   
  358    0 to request clients to close connections as soon as possible.  This    
  359    is useful when server resources become very low or a denial-of-         
  360    service attack is detected and further maximises the shifting of        
  361    TIME_WAIT state to well-behaved clients.                                
  362                                                                            
  363    However, it should be noted that RFC 6891 states:                       
  364                                                                            
  365       Lack of presence of an OPT record in a request MUST be taken as an   
  366       indication that the requestor does not implement any part of this    
  367       specification and that the responder MUST NOT include an OPT         
  368       record in its response.                                              
  369                                                                            
  370    Since servers must be faithful to this specification even on a          
  371    persistent TCP connection, it means that (following the initial         
  372    exchange of timeouts) a server may not be presented with the            
  373    opportunity to signal a change in the idle timeout associated with a    
  374    connection if the client does not send any further requests             
  375    containing EDNS0 OPT RRs.  This limitation makes persistent             
  376    connection handling via an initial idle timeout signal more             
  377                                                                            
  378                                                                            
  379                                                                            
  380                                                                            
  381                                                                            
  382 Wouters, et al.              Standards Track                    [Page 7]   

  383 RFC 7828           The edns-tcp-keepalive EDNS0 Option        April 2016   
  384                                                                            
  385                                                                            
  386    attractive than a mechanism that establishes default persistence and    
  387    then uses a connection close signal (in a similar manner to HTTP 1.1    
  388    [RFC7230]).                                                             
  389                                                                            
  390    If a client includes the edns-tcp-keepalive option in the first         
  391    query, it SHOULD include an EDNS0 OPT RR periodically in any further    
  392    messages it sends during the TCP session.  This will increase the       
  393    chance of the client being notified should the server modify the        
  394    timeout associated with a session.  The algorithm for choosing when     
  395    to do this is out of scope of this document and is left up to the       
  396    implementor and/or operator.                                            
  397                                                                            
  398    DNS clients and servers MAY close a TCP session at any time in order    
  399    to manage local resource constraints.  The algorithm by which clients   
  400    and servers rank active TCP sessions in order to determine which to     
  401    close is not specified in this document.                                
  402                                                                            
  403 3.5.  Non-clean Paths                                                      
  404                                                                            
  405    Many paths between DNS clients and servers suffer from poor hygiene,    
  406    limiting the free flow of DNS messages that include particular EDNS0    
  407    options or messages that exceed a particular size.  A fallback          
  408    strategy similar to that described in [RFC6891], Section 6.2.2 SHOULD   
  409    be employed to avoid persistent interference due to non-clean paths.    
  410                                                                            
  411 3.6.  Anycast Considerations                                               
  412                                                                            
  413    DNS servers of various types are commonly deployed using anycast        
  414    [RFC4786].                                                              
  415                                                                            
  416    Changes in network topology between clients and anycast servers may     
  417    cause disruption to TCP sessions making use of edns-tcp-keepalive       
  418    more often than with TCP sessions that omit it, since the TCP           
  419    sessions are expected to be longer lived.  It might be possible for     
  420    anycast servers to avoid disruption due to topology changes by making   
  421    use of TCP multipath [RFC6824] to anchor the server side of the TCP     
  422    connection to an unambiguously unicast address.                         
  423                                                                            
  424 4.  Intermediary Considerations                                            
  425                                                                            
  426    It is RECOMMENDED that DNS intermediaries that terminate TCP            
  427    connections implement edns-tcp-keepalive.  An intermediary that does    
  428    not implement edns-tcp-keepalive but sits between a client and server   
  429    that both support edns-tcp-keepalive might close idle connections       
  430    unnecessarily.                                                          
  431                                                                            
  432                                                                            
  433                                                                            
  434                                                                            
  435                                                                            
  436                                                                            
  437 Wouters, et al.              Standards Track                    [Page 8]   

  438 RFC 7828           The edns-tcp-keepalive EDNS0 Option        April 2016   
  439                                                                            
  440                                                                            
  441 5.  Security Considerations                                                
  442                                                                            
  443    The edns-tcp-keepalive option can potentially be abused to request      
  444    large numbers of long-lived sessions in a quick burst.  When a DNS      
  445    server detects abusive behaviour, it SHOULD immediately close the TCP   
  446    connection and free the resources used.                                 
  447                                                                            
  448    Servers could choose to monitor client behaviour with respect to the    
  449    edns-tcp-keepalive option to build up profiles of clients that do not   
  450    honour the specified timeout.                                           
  451                                                                            
  452    Readers are advised to familiarise themselves with the security         
  453    considerations outlined in [RFC7766]                                    
  454                                                                            
  455 6.  IANA Considerations                                                    
  456                                                                            
  457    IANA has assigned an EDNS0 option code for the edns-tcp-keepalive       
  458    option from the "DNS EDNS0 Option Codes (OPT)" registry as follows:     
  459                                                                            
  460            +-------+--------------------+----------+-----------+           
  461            | Value | Name               | Status   | Reference |           
  462            +-------+--------------------+----------+-----------+           
  463            | 11    | edns-tcp-keepalive | Standard | RFC 7828  |           
  464            +-------+--------------------+----------+-----------+           
  465                                                                            
  466 7.  References                                                             
  467                                                                            
  468 7.1.  Normative References                                                 
  469                                                                            
  470    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
  471               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,      
  472               November 1987, <http://www.rfc-editor.org/info/rfc1035>.     
  473                                                                            
  474    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
  475               Requirement Levels", BCP 14, RFC 2119,                       
  476               DOI 10.17487/RFC2119, March 1997,                            
  477               <http://www.rfc-editor.org/info/rfc2119>.                    
  478                                                                            
  479    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
  480               Rose, "DNS Security Introduction and Requirements",          
  481               RFC 4033, DOI 10.17487/RFC4033, March 2005,                  
  482               <http://www.rfc-editor.org/info/rfc4033>.                    
  483                                                                            
  484    [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast            
  485               Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,          
  486               December 2006, <http://www.rfc-editor.org/info/rfc4786>.     
  487                                                                            
  488                                                                            
  489                                                                            
  490                                                                            
  491                                                                            
  492 Wouters, et al.              Standards Track                    [Page 9]   

  493 RFC 7828           The edns-tcp-keepalive EDNS0 Option        April 2016   
  494                                                                            
  495                                                                            
  496    [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms    
  497               for DNS (EDNS(0))", STD 75, RFC 6891,                        
  498               DOI 10.17487/RFC6891, April 2013,                            
  499               <http://www.rfc-editor.org/info/rfc6891>.                    
  500                                                                            
  501    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer   
  502               Protocol (HTTP/1.1): Message Syntax and Routing",            
  503               RFC 7230, DOI 10.17487/RFC7230, June 2014,                   
  504               <http://www.rfc-editor.org/info/rfc7230>.                    
  505                                                                            
  506    [RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and    
  507               D. Wessels, "DNS Transport over TCP - Implementation         
  508               Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,   
  509               <http://www.rfc-editor.org/info/rfc7766>.                    
  510                                                                            
  511 7.2.  Informative References                                               
  512                                                                            
  513    [CHAIN-QUERY]                                                           
  514               Wouters, P., "Chain Query requests in DNS", Work in          
  515               Progress, draft-ietf-dnsop-edns-chain-query-07, February     
  516               2016.                                                        
  517                                                                            
  518    [DNS-over-TLS]                                                          
  519               Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,     
  520               and P. Hoffman, "Specification for DNS over TLS", Work in    
  521               Progress, draft-ietf-dprive-dns-over-tls-09, March 2016.     
  522                                                                            
  523    [fragmentation-considered-poisonous]                                    
  524               Herzberg, A. and H. Shulman, "Fragmentation Considered       
  525               Poisonous", arXiv: 1205.4011, May 2012,                      
  526               <http://arxiv.org/abs/1205.4011>.                            
  527                                                                            
  528    [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,       
  529               "TCP Extensions for Multipath Operation with Multiple        
  530               Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,    
  531               <http://www.rfc-editor.org/info/rfc6824>.                    
  532                                                                            
  533    [RRL]      Vixie, P. and V. Schryver, "DNS Response Rate Limiting       
  534               (DNS RRL)", ISC-TN 2012-1-Draft1, April 2012,                
  535               <https://ftp.isc.org/isc/pubs/tn/isc-tn-2012-1.txt>.         
  536                                                                            
  537                                                                            
  538                                                                            
  539                                                                            
  540                                                                            
  541                                                                            
  542                                                                            
  543                                                                            
  544                                                                            
  545                                                                            
  546                                                                            
  547 Wouters, et al.              Standards Track                   [Page 10]   

  548 RFC 7828           The edns-tcp-keepalive EDNS0 Option        April 2016   
  549                                                                            
  550                                                                            
  551 Acknowledgements                                                           
  552                                                                            
  553    The authors acknowledge the contributions of Jinmei TATUYA and Mark     
  554    Andrews.  Thanks to Duane Wessels for detailed review and the many      
  555    others who contributed to the mailing list discussion.                  
  556                                                                            
  557 Authors' Addresses                                                         
  558                                                                            
  559    Paul Wouters                                                            
  560    Red Hat                                                                 
  561                                                                            
  562    Email: pwouters@redhat.com                                              
  563                                                                            
  564                                                                            
  565    Joe Abley                                                               
  566    Dyn, Inc.                                                               
  567    103-186 Albert Street                                                   
  568    London, ON  N6A 1M1                                                     
  569    Canada                                                                  
  570                                                                            
  571    Phone: +1 519 670 9327                                                  
  572    Email: jabley@dyn.com                                                   
  573                                                                            
  574                                                                            
  575    Sara Dickinson                                                          
  576    Sinodun Internet Technologies                                           
  577    Magdalen Centre                                                         
  578    Oxford Science Park                                                     
  579    Oxford  OX4 4GA                                                         
  580    United Kingdom                                                          
  581                                                                            
  582    Email: sara@sinodun.com                                                 
  583    URI:   http://sinodun.com                                               
  584                                                                            
  585                                                                            
  586    Ray Bellis                                                              
  587    Internet Systems Consortium, Inc                                        
  588    950 Charter Street                                                      
  589    Redwood City, CA  94063                                                 
  590    United States                                                           
  591                                                                            
  592    Phone: +1 650 423 1200                                                  
  593    Email: ray@isc.org                                                      
  594    URI:   http://www.isc.org                                               
  595                                                                            
  596                                                                            
  597                                                                            
  598                                                                            
  599                                                                            
  600                                                                            
  601                                                                            
  602 Wouters, et al.              Standards Track                   [Page 11]   
  603                                                                            

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.

GLOBAL V. Risk, ISC.orgBIND 9 implementation note2022-08-15

This RFC is implemented in BIND 9.18 (all versions).