1 Internet Engineering Task Force (IETF)                        C. Huitema   
    2 Request for Comments: 9250                          Private Octopus Inc.   
    3 Category: Standards Track                                   S. Dickinson   
    4 ISSN: 2070-1721                                               Sinodun IT   
    5                                                                A. Mankin   
    6                                                               Salesforce   
    7                                                                 May 2022   
   10                   DNS over Dedicated QUIC Connections                      
   12 Abstract                                                                   
   14    This document describes the use of QUIC to provide transport            
   15    confidentiality for DNS.  The encryption provided by QUIC has similar   
   16    properties to those provided by TLS, while QUIC transport eliminates    
   17    the head-of-line blocking issues inherent with TCP and provides more    
   18    efficient packet-loss recovery than UDP.  DNS over QUIC (DoQ) has       
   19    privacy properties similar to DNS over TLS (DoT) specified in RFC       
   20    7858, and latency characteristics similar to classic DNS over UDP.      
   21    This specification describes the use of DoQ as a general-purpose        
   22    transport for DNS and includes the use of DoQ for stub to recursive,    
   23    recursive to authoritative, and zone transfer scenarios.                
   25 Status of This Memo                                                        
   27    This is an Internet Standards Track document.                           
   29    This document is a product of the Internet Engineering Task Force       
   30    (IETF).  It represents the consensus of the IETF community.  It has     
   31    received public review and has been approved for publication by the     
   32    Internet Engineering Steering Group (IESG).  Further information on     
   33    Internet Standards is available in Section 2 of RFC 7841.               
   35    Information about the current status of this document, any errata,      
   36    and how to provide feedback on it may be obtained at                    
   37    https://www.rfc-editor.org/info/rfc9250.                                
   39 Copyright Notice                                                           
   41    Copyright (c) 2022 IETF Trust and the persons identified as the         
   42    document authors.  All rights reserved.                                 
   44    This document is subject to BCP 78 and the IETF Trust's Legal           
   45    Provisions Relating to IETF Documents                                   
   46    (https://trustee.ietf.org/license-info) in effect on the date of        
   47    publication of this document.  Please review these documents            
   48    carefully, as they describe your rights and restrictions with respect   
   49    to this document.  Code Components extracted from this document must    
   50    include Revised BSD License text as described in Section 4.e of the     
   51    Trust Legal Provisions and are provided without warranty as described   
   52    in the Revised BSD License.                                             
   54 Table of Contents                                                          
   56    1.  Introduction                                                        
   57    2.  Key Words                                                           
   58    3.  Design Considerations                                               
   59      3.1.  Provide DNS Privacy                                             
   60      3.2.  Design for Minimum Latency                                      
   61      3.3.  Middlebox Considerations                                        
   62      3.4.  No Server-Initiated Transactions                                
   63    4.  Specifications                                                      
   64      4.1.  Connection Establishment                                        
   65        4.1.1.  Port Selection                                              
   66      4.2.  Stream Mapping and Usage                                        
   67        4.2.1.  DNS Message IDs                                             
   68      4.3.  DoQ Error Codes                                                 
   69        4.3.1.  Transaction Cancellation                                    
   70        4.3.2.  Transaction Errors                                          
   71        4.3.3.  Protocol Errors                                             
   72        4.3.4.  Alternative Error Codes                                     
   73      4.4.  Connection Management                                           
   74      4.5.  Session Resumption and 0-RTT                                    
   75      4.6.  Message Sizes                                                   
   76    5.  Implementation Requirements                                         
   77      5.1.  Authentication                                                  
   78      5.2.  Fallback to Other Protocols on Connection Failure               
   79      5.3.  Address Validation                                              
   80      5.4.  Padding                                                         
   81      5.5.  Connection Handling                                             
   82        5.5.1.  Connection Reuse                                            
   83        5.5.2.  Resource Management                                         
   84        5.5.3.  Using 0-RTT and Session Resumption                          
   85        5.5.4.  Controlling Connection Migration for Privacy                
   86      5.6.  Processing Queries in Parallel                                  
   87      5.7.  Zone Transfer                                                   
   88      5.8.  Flow Control Mechanisms                                         
   89    6.  Security Considerations                                             
   90    7.  Privacy Considerations                                              
   91      7.1.  Privacy Issues with 0-RTT data                                  
   92      7.2.  Privacy Issues with Session Resumption                          
   93      7.3.  Privacy Issues with Address Validation Tokens                   
   94      7.4.  Privacy Issues with Long Duration Sessions                      
   95      7.5.  Traffic Analysis                                                
   96    8.  IANA Considerations                                                 
   97      8.1.  Registration of a DoQ Identification String                     
   98      8.2.  Reservation of a Dedicated Port                                 
   99      8.3.  Reservation of an Extended DNS Error Code: Too Early            
  100      8.4.  DNS-over-QUIC Error Codes Registry                              
  101    9.  References                                                          
  102      9.1.  Normative References                                            
  103      9.2.  Informative References                                          
  104    Appendix A.  The NOTIFY Service                                         
  105    Acknowledgements                                                        
  106    Authors' Addresses                                                      
  108 1.  Introduction                                                           
  110    Domain Name System (DNS) concepts are specified in "Domain names -      
  111    concepts and facilities" [RFC1034].  The transmission of DNS queries    
  112    and responses over UDP and TCP is specified in "Domain names -          
  113    implementation and specification" [RFC1035].                            
  115    This document presents a mapping of the DNS protocol over the QUIC      
  116    transport [RFC9000] [RFC9001].  DNS over QUIC is referred to here as    
  117    DoQ, in line with "DNS Terminology" [DNS-TERMS].                        
  119    The goals of the DoQ mapping are:                                       
  121    1.  Provide the same DNS privacy protection as DoT [RFC7858].  This     
  122        includes an option for the client to authenticate the server by     
  123        means of an authentication domain name as specified in "Usage       
  124        Profiles for DNS over TLS and DNS over DTLS" [RFC8310].             
  126    2.  Provide an improved level of source address validation for DNS      
  127        servers compared to classic DNS over UDP.                           
  129    3.  Provide a transport that does not impose path MTU limitations on    
  130        the size of DNS responses it can send.                              
  132    In order to achieve these goals, and to support ongoing work on         
  133    encryption of DNS, the scope of this document includes:                 
  135    *  the "stub to recursive resolver" scenario (also called the "stub     
  136       to recursive" scenario in this document)                             
  138    *  the "recursive resolver to authoritative nameserver" scenario        
  139       (also called the "recursive to authoritative" scenario in this       
  140       document), and                                                       
  142    *  the "nameserver to nameserver" scenario (mainly used for zone        
  143       transfers (XFR) [RFC1995] [RFC5936]).                                
  145    In other words, this document specifies QUIC as a general-purpose       
  146    transport for DNS.                                                      
  148    The specific non-goals of this document are:                            
  150    1.  No attempt is made to evade potential blocking of DoQ traffic by    
  151        middleboxes.                                                        
  153    2.  No attempt to support server-initiated transactions, which are      
  154        used only in DNS Stateful Operations (DSO) [RFC8490].               
  156    Specifying the transmission of an application over QUIC requires        
  157    specifying how the application's messages are mapped to QUIC streams,   
  158    and generally how the application will use QUIC.  This is done for      
  159    HTTP in "Hypertext Transfer Protocol Version 3 (HTTP/3)" [HTTP/3].      
  160    The purpose of this document is to define the way DNS messages can be   
  161    transmitted over QUIC.                                                  
  163    DNS over HTTPS (DoH) [RFC8484] can be used with HTTP/3 to get some of   
  164    the benefits of QUIC.  However, a lightweight direct mapping for DoQ    
  165    can be regarded as a more natural fit for both the recursive to         
  166    authoritative and zone transfer scenarios, which rarely involve         
  167    intermediaries.  In these scenarios, the additional overhead of HTTP    
  168    is not offset by, for example, benefits of HTTP proxying and caching    
  169    behavior.                                                               
  171    In this document, Section 3 presents the reasoning that guided the      
  172    proposed design.  Section 4 specifies the actual mapping of DoQ.        
  173    Section 5 presents guidelines on the implementation, usage, and         
  174    deployment of DoQ.                                                      
  176 2.  Key Words                                                              
  178    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  180    "OPTIONAL" in this document are to be interpreted as described in       
  181    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all      
  182    capitals, as shown here.                                                
  184 3.  Design Considerations                                                  
  186    This section and its subsections present the design guidelines that     
  187    were used for DoQ.  While all other sections in this document are       
  188    normative, this section is informative in nature.                       
  190 3.1.  Provide DNS Privacy                                                  
  192    DoT [RFC7858] defines how to mitigate some of the issues described in   
  193    "DNS Privacy Considerations" [RFC9076] by specifying how to transmit    
  194    DNS messages over TLS.  The "Usage Profiles for DNS over TLS and DNS    
  195    over DTLS" [RFC8310] specify Strict and Opportunistic usage profiles    
  196    for DoT including how stub resolvers can authenticate recursive         
  197    resolvers.                                                              
  199    QUIC connection setup includes the negotiation of security parameters   
  200    using TLS, as specified in "Using TLS to Secure QUIC" [RFC9001],        
  201    enabling encryption of the QUIC transport.  Transmitting DNS messages   
  202    over QUIC will provide essentially the same privacy protections as      
  203    DoT [RFC7858] including Strict and Opportunistic usage profiles         
  204    [RFC8310].  Further discussion on this is provided in Section 7.        
  206 3.2.  Design for Minimum Latency                                           
  208    QUIC is specifically designed to reduce protocol-induced delays, with   
  209    features such as:                                                       
  211    1.  Support for 0-RTT data during session resumption.                   
  213    2.  Support for advanced packet-loss recovery procedures as specified   
  214        in "QUIC Loss Detection and Congestion Control" [RFC9002].          
  216    3.  Mitigation of head-of-line blocking by allowing parallel delivery   
  217        of data on multiple streams.                                        
  219    This mapping of DNS to QUIC will take advantage of these features in    
  220    three ways:                                                             
  222    1.  Optional support for sending 0-RTT data during session resumption   
  223        (the security and privacy implications of this are discussed in     
  224        later sections).                                                    
  226    2.  Long-lived QUIC connections over which multiple DNS transactions    
  227        are performed, generating the sustained traffic required to         
  228        benefit from advanced recovery features.                            
  230    3.  Mapping of each DNS Query/Response transaction to a separate        
  231        stream, to mitigate head-of-line blocking.  This enables servers    
  232        to respond to queries "out of order".  It also enables clients to   
  233        process responses as soon as they arrive, without having to wait    
  234        for in-order delivery of responses previously posted by the         
  235        server.                                                             
  237    These considerations are reflected in the mapping of DNS traffic to     
  238    QUIC streams in Section 4.2.                                            
  240 3.3.  Middlebox Considerations                                             
  242    Using QUIC might allow a protocol to disguise its purpose from          
  243    devices on the network path using encryption and traffic analysis       
  244    resistance techniques like padding, traffic pacing, and traffic         
  245    shaping.  This specification does not include any measures that are     
  246    designed to avoid such classification; the padding mechanisms defined   
  247    in Section 5.4 are intended to obfuscate the specific records           
  248    contained in DNS queries and responses, but not the fact that this is   
  249    DNS traffic.  Consequently, firewalls and other middleboxes might be    
  250    able to distinguish DoQ from other protocols that use QUIC, like        
  251    HTTP, and apply different treatment.                                    
  253    The lack of measures in this specification to avoid protocol            
  254    classification is not an endorsement of such practices.                 
  256 3.4.  No Server-Initiated Transactions                                     
  258    As stated in Section 1, this document does not specify support for      
  259    server-initiated transactions within established DoQ connections.       
  260    That is, only the initiator of the DoQ connection may send queries      
  261    over the connection.                                                    
  263    DSO does support server-initiated transactions within existing          
  264    connections.  However, DoQ as defined here does not meet the criteria   
  265    for an applicable transport for DSO because it does not guarantee in-   
  266    order delivery of messages; see Section 4.2 of [RFC8490].               
  268 4.  Specifications                                                         
  270 4.1.  Connection Establishment                                             
  272    DoQ connections are established as described in the QUIC transport      
  273    specification [RFC9000].  During connection establishment, DoQ          
  274    support is indicated by selecting the Application-Layer Protocol        
  275    Negotiation (ALPN) token "doq" in the crypto handshake.                 
  277 4.1.1.  Port Selection                                                     
  279    By default, a DNS server that supports DoQ MUST listen for and accept   
  280    QUIC connections on the dedicated UDP port 853 (Section 8), unless      
  281    there is a mutual agreement to use another port.                        
  283    By default, a DNS client desiring to use DoQ with a particular server   
  284    MUST establish a QUIC connection to UDP port 853 on the server,         
  285    unless there is a mutual agreement to use another port.                 
  287    DoQ connections MUST NOT use UDP port 53.  This recommendation          
  288    against use of port 53 for DoQ is to avoid confusion between DoQ and    
  289    the use of DNS over UDP [RFC1035].  The risk of confusion exists even   
  290    if two parties agreed on port 53, as other parties without knowledge    
  291    of that agreement might still try to use that port.                     
  293    In the stub to recursive scenario, the use of port 443 as a mutually    
  294    agreed alternative port can be operationally beneficial, since port     
  295    443 is used by many services using QUIC and HTTP-3 and is thus less     
  296    likely to be blocked than other ports.  Several mechanisms for stubs    
  297    to discover recursives offering encrypted transports, including the     
  298    use of custom ports, are the subject of ongoing work.                   
  300 4.2.  Stream Mapping and Usage                                             
  302    The mapping of DNS traffic over QUIC streams takes advantage of the     
  303    QUIC stream features detailed in Section 2 of [RFC9000], the QUIC       
  304    transport specification.                                                
  306    DNS query/response traffic [RFC1034] [RFC1035] follows a simple         
  307    pattern in which the client sends a query, and the server provides      
  308    one or more responses (multiple responses can occur in zone             
  309    transfers).                                                             
  311    The mapping specified here requires that the client select a separate   
  312    QUIC stream for each query.  The server then uses the same stream to    
  313    provide all the response messages for that query.  In order for         
  314    multiple responses to be parsed, a 2-octet length field is used in      
  315    exactly the same way as the 2-octet length field defined for DNS over   
  316    TCP [RFC1035].  The practical result of this is that the content of     
  317    each QUIC stream is exactly the same as the content of a TCP            
  318    connection that would manage exactly one query.                         
  320    All DNS messages (queries and responses) sent over DoQ connections      
  321    MUST be encoded as a 2-octet length field followed by the message       
  322    content as specified in [RFC1035].                                      
  324    The client MUST select the next available client-initiated              
  325    bidirectional stream for each subsequent query on a QUIC connection,    
  326    in conformance with the QUIC transport specification [RFC9000].         
  327    Packet losses and other network events might cause queries to arrive    
  328    in a different order.  Servers SHOULD process queries as they arrive,   
  329    as not doing so would cause unnecessary delays.                         
  331    The client MUST send the DNS query over the selected stream and MUST    
  332    indicate through the STREAM FIN mechanism that no further data will     
  333    be sent on that stream.                                                 
  335    The server MUST send the response(s) on the same stream and MUST        
  336    indicate, after the last response, through the STREAM FIN mechanism     
  337    that no further data will be sent on that stream.                       
  339    Therefore, a single DNS transaction consumes a single bidirectional     
  340    client-initiated stream.  This means that the client's first query      
  341    occurs on QUIC stream 0, the second on 4, and so on (see Section 2.1    
  342    of [RFC9000]).                                                          
  344    Servers MAY defer processing of a query until the STREAM FIN has been   
  345    indicated on the stream selected by the client.                         
  347    Servers and clients MAY monitor the number of "dangling" streams.       
  348    These are open streams where the following events have not occurred     
  349    after implementation-defined timeouts:                                  
  351    *  the expected queries or responses have not been received or,         
  353    *  the expected queries or responses have been received but not the     
  354       STREAM FIN                                                           
  356    Implementations MAY impose a limit on the number of such dangling       
  357    streams.  If limits are encountered, implementations MAY close the      
  358    connection.                                                             
  360 4.2.1.  DNS Message IDs                                                    
  362    When sending queries over a QUIC connection, the DNS Message ID MUST    
  363    be set to 0.  The stream mapping for DoQ allows for unambiguous         
  364    correlation of queries and responses, so the Message ID field is not    
  365    required.                                                               
  367    This has implications for proxying DoQ messages to and from other       
  368    transports.  For example, proxies may have to manage the fact that      
  369    DoQ can support a larger number of outstanding queries on a single      
  370    connection than, for example, DNS over TCP, because DoQ is not          
  371    limited by the Message ID space.  This issue already exists for DoH,    
  372    where a Message ID of 0 is recommended.                                 
  374    When forwarding a DNS message from DoQ over another transport, a DNS    
  375    Message ID MUST be generated according to the rules of the protocol     
  376    that is in use.  When forwarding a DNS message from another transport   
  377    over DoQ, the Message ID MUST be set to 0.                              
  379 4.3.  DoQ Error Codes                                                      
  381    The following error codes are defined for use when abruptly             
  382    terminating streams, for use as application protocol error codes when   
  383    aborting reading of streams, or for immediately closing connections:    
  385    DOQ_NO_ERROR (0x0):  No error.  This is used when the connection or     
  386       stream needs to be closed, but there is no error to signal.          
  388    DOQ_INTERNAL_ERROR (0x1):  The DoQ implementation encountered an        
  389       internal error and is incapable of pursuing the transaction or the   
  390       connection.                                                          
  392    DOQ_PROTOCOL_ERROR (0x2):  The DoQ implementation encountered a         
  393       protocol error and is forcibly aborting the connection.              
  395    DOQ_REQUEST_CANCELLED (0x3):  A DoQ client uses this to signal that     
  396       it wants to cancel an outstanding transaction.                       
  398    DOQ_EXCESSIVE_LOAD (0x4):  A DoQ implementation uses this to signal     
  399       when closing a connection due to excessive load.                     
  401    DOQ_UNSPECIFIED_ERROR (0x5):  A DoQ implementation uses this in the     
  402       absence of a more specific error code.                               
  404    DOQ_ERROR_RESERVED (0xd098ea5e):  An alternative error code used for    
  405       tests.                                                               
  407    See Section 8.4 for details on registering new error codes.             
  409 4.3.1.  Transaction Cancellation                                           
  411    In QUIC, sending STOP_SENDING requests that a peer cease transmission   
  412    on a stream.  If a DoQ client wishes to cancel an outstanding           
  413    request, it MUST issue a QUIC STOP_SENDING, and it SHOULD use the       
  414    error code DOQ_REQUEST_CANCELLED.  It MAY use a more specific error     
  415    code registered according to Section 8.4.  The STOP_SENDING request     
  416    may be sent at any time but will have no effect if the server           
  417    response has already been sent, in which case the client will simply    
  418    discard the incoming response.  The corresponding DNS transaction       
  419    MUST be abandoned.                                                      
  421    Servers that receive STOP_SENDING act in accordance with Section 3.5    
  422    of [RFC9000].  Servers SHOULD NOT continue processing a DNS             
  423    transaction if they receive a STOP_SENDING.                             
  425    Servers MAY impose implementation limits on the total number or rate    
  426    of cancellation requests.  If limits are encountered, servers MAY       
  427    close the connection.  In this case, servers wanting to help client     
  428    debugging MAY use the error code DOQ_EXCESSIVE_LOAD.  There is always   
  429    a trade-off between helping good faith clients debug issues and         
  430    allowing denial-of-service attackers to test server defenses;           
  431    depending on circumstances servers might very well choose to send       
  432    different error codes.                                                  
  434    Note that this mechanism provides a way for secondaries to cancel a     
  435    single zone transfer occurring on a given stream without having to      
  436    close the QUIC connection.                                              
  438    Servers MUST NOT continue processing a DNS transaction if they          
  439    receive a RESET_STREAM request from the client before the client        
  440    indicates the STREAM FIN.  The server MUST issue a RESET_STREAM to      
  441    indicate that the transaction is abandoned unless:                      
  443    *  it has already done so for another reason or                         
  445    *  it has already both sent the response and indicated the STREAM       
  446       FIN.                                                                 
  448 4.3.2.  Transaction Errors                                                 
  450    Servers normally complete transactions by sending a DNS response (or    
  451    responses) on the transaction's stream, including cases where the DNS   
  452    response indicates a DNS error.  For example, a client SHOULD be        
  453    notified of a Server Failure (SERVFAIL, [RFC1035]) through a response   
  454    with the Response Code set to SERVFAIL.                                 
  456    If a server is incapable of sending a DNS response due to an internal   
  457    error, it SHOULD issue a QUIC RESET_STREAM frame.  The error code       
  458    SHOULD be set to DOQ_INTERNAL_ERROR.  The corresponding DNS             
  459    transaction MUST be abandoned.  Clients MAY limit the number of         
  460    unsolicited QUIC RESET_STREAM frames received on a connection before    
  461    choosing to close the connection.                                       
  463    Note that this mechanism provides a way for primaries to abort a        
  464    single zone transfer occurring on a given stream without having to      
  465    close the QUIC connection.                                              
  467 4.3.3.  Protocol Errors                                                    
  469    Other error scenarios can occur due to malformed, incomplete, or        
  470    unexpected messages during a transaction.  These include (but are not   
  471    limited to):                                                            
  473    *  a client or server receives a message with a non-zero Message ID     
  475    *  a client or server receives a STREAM FIN before receiving all the    
  476       bytes for a message indicated in the 2-octet length field            
  478    *  a client receives a STREAM FIN before receiving all the expected     
  479       responses                                                            
  481    *  a server receives more than one query on a stream                    
  483    *  a client receives a different number of responses on a stream than   
  484       expected (e.g., multiple responses to a query for an A record)       
  486    *  a client receives a STOP_SENDING request                             
  488    *  the client or server does not indicate the expected STREAM FIN       
  489       after sending requests or responses (see Section 4.2)                
  491    *  an implementation receives a message containing the edns-tcp-        
  492       keepalive EDNS(0) Option [RFC7828] (see Section 5.5.2)               
  494    *  a client or a server attempts to open a unidirectional QUIC stream   
  496    *  a server attempts to open a server-initiated bidirectional QUIC      
  497       stream                                                               
  499    *  a server receives a "replayable" transaction in 0-RTT data (for      
  500       servers not willing to handle this case, see Section 4.5)            
  502    If a peer encounters such an error condition, it is considered a        
  503    fatal error.  It SHOULD forcibly abort the connection using QUIC's      
  504    CONNECTION_CLOSE mechanism and SHOULD use the DoQ error code            
  505    DOQ_PROTOCOL_ERROR.  In some cases, it MAY instead silently abandon     
  506    the connection, which uses fewer of the local resources but makes       
  507    debugging at the offending node more difficult.                         
  509    It is noted that the restrictions on use of the above EDNS(0) option    
  510    has implications for proxying messages from TCP/DoT/DoH over DoQ.       
  512 4.3.4.  Alternative Error Codes                                            
  514    This specification describes specific error codes in Sections 4.3.1,    
  515    4.3.2, and 4.3.3.  These error codes are meant to facilitate            
  516    investigation of failures and other incidents.  New error codes may     
  517    be defined in future versions of DoQ or registered as specified in      
  518    Section 8.4.                                                            
  520    Because new error codes can be defined without negotiation, use of an   
  521    error code in an unexpected context or receipt of an unknown error      
  522    code MUST be treated as equivalent to DOQ_UNSPECIFIED_ERROR.            
  524    Implementations MAY wish to test the support for the error code         
  525    extension mechanism by using error codes not listed in this document,   
  526    or they MAY use DOQ_ERROR_RESERVED.                                     
  528 4.4.  Connection Management                                                
  530    Section 10 of [RFC9000], the QUIC transport specification, specifies    
  531    that connections can be closed in three ways:                           
  533    *  idle timeout                                                         
  535    *  immediate close                                                      
  537    *  stateless reset                                                      
  539    Clients and servers implementing DoQ SHOULD negotiate use of the idle   
  540    timeout.  Closing on idle timeout is done without any packet            
  541    exchange, which minimizes protocol overhead.  Per Section 10.1 of       
  542    [RFC9000], the QUIC transport specification, the effective value of     
  543    the idle timeout is computed as the minimum of the values advertised    
  544    by the two endpoints.  Practical considerations on setting the idle     
  545    timeout are discussed in Section 5.5.2.                                 
  547    Clients SHOULD monitor the idle time incurred on their connection to    
  548    the server, defined by the time spent since the last packet from the    
  549    server has been received.  When a client prepares to send a new DNS     
  550    query to the server, it SHOULD check whether the idle time is           
  551    sufficiently lower than the idle timer.  If it is, the client SHOULD    
  552    send the DNS query over the existing connection.  If not, the client    
  553    SHOULD establish a new connection and send the query over that          
  554    connection.                                                             
  556    Clients MAY discard their connections to the server before the idle     
  557    timeout expires.  A client that has outstanding queries SHOULD close    
  558    the connection explicitly using QUIC's CONNECTION_CLOSE mechanism and   
  559    the DoQ error code DOQ_NO_ERROR.                                        
  561    Clients and servers MAY close the connection for a variety of other     
  562    reasons, indicated using QUIC's CONNECTION_CLOSE.  Client and servers   
  563    that send packets over a connection discarded by their peer might       
  564    receive a stateless reset indication.  If a connection fails, all the   
  565    in-progress transactions on that connection MUST be abandoned.          
  567 4.5.  Session Resumption and 0-RTT                                         
  569    A client MAY take advantage of the session resumption and 0-RTT         
  570    mechanisms supported by QUIC transport [RFC9000] and QUIC TLS           
  571    [RFC9001] if the server supports them.  Clients SHOULD consider         
  572    potential privacy issues associated with session resumption before      
  573    deciding to use this mechanism and specifically evaluate the trade-     
  574    offs presented in the various sections of this document.  The privacy   
  575    issues are detailed in Sections 7.1 and 7.2, and the implementation     
  576    considerations are discussed in Section 5.5.3.                          
  578    The 0-RTT mechanism MUST NOT be used to send DNS requests that are      
  579    not "replayable" transactions.  In this specification, only             
  580    transactions that have an OPCODE of QUERY or NOTIFY are considered      
  581    replayable; therefore, other OPCODES MUST NOT be sent in 0-RTT data.    
  582    See Appendix A for a detailed discussion of why NOTIFY is included      
  583    here.                                                                   
  585    Servers MAY support session resumption, and MAY do that with or         
  586    without supporting 0-RTT, using the mechanisms described in             
  587    Section 4.6.1 of [RFC9001].  Servers supporting 0-RTT MUST NOT          
  588    immediately process non-replayable transactions received in 0-RTT       
  589    data but instead MUST adopt one of the following behaviors:             
  591    *  Queue the offending transaction and only process it after the QUIC   
  592       handshake has been completed, as defined in Section 4.1.1 of         
  593       [RFC9001].                                                           
  595    *  Reply to the offending transaction with a response code REFUSED      
  596       and an Extended DNS Error Code (EDE) "Too Early" using the           
  597       extended RCODE mechanisms defined in [RFC6891] and the extended      
  598       DNS errors defined in [RFC8914]; see Section 8.3.                    
  600    *  Close the connection with the error code DOQ_PROTOCOL_ERROR.         
  602 4.6.  Message Sizes                                                        
  604    DoQ queries and responses are sent on QUIC streams, which in theory     
  605    can carry up to 2^62 bytes.  However, DNS messages are restricted in    
  606    practice to a maximum size of 65535 bytes.  This maximum size is        
  607    enforced by the use of a 2-octet message length field in DNS over TCP   
  608    [RFC1035] and DoT [RFC7858], and by the definition of the               
  609    "application/dns-message" for DoH [RFC8484].  DoQ enforces the same     
  610    restriction.                                                            
  612    The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] allow peers to     
  613    specify the UDP message size.  This parameter is ignored by DoQ.  DoQ   
  614    implementations always assume that the maximum message size is 65535    
  615    bytes.                                                                  
  617 5.  Implementation Requirements                                            
  619 5.1.  Authentication                                                       
  621    For the stub to recursive scenario, the authentication requirements     
  622    are the same as described in DoT [RFC7858] and "Usage Profiles for      
  623    DNS over TLS and DNS over DTLS" [RFC8310].  [RFC8932] states that DNS   
  624    privacy services SHOULD provide credentials that clients can use to     
  625    authenticate the server.  Given this, and to align with the             
  626    authentication model for DoH, DoQ stubs SHOULD use a Strict usage       
  627    profile.  Client authentication for the encrypted stub to recursive     
  628    scenario is not described in any DNS RFC.                               
  630    For zone transfer, the authentication requirements are the same as      
  631    described in [RFC9103].                                                 
  633    For the recursive to authoritative scenario, authentication             
  634    requirements are unspecified at the time of writing and are the         
  635    subject of ongoing work in the DPRIVE WG.                               
  637 5.2.  Fallback to Other Protocols on Connection Failure                    
  639    If the establishment of the DoQ connection fails, clients MAY attempt   
  640    to fall back to DoT and then potentially cleartext, as specified in     
  641    DoT [RFC7858] and "Usage Profiles for DNS over TLS and DNS over DTLS"   
  642    [RFC8310], depending on their usage profile.                            
  644    DNS clients SHOULD remember server IP addresses that don't support      
  645    DoQ.  Mobile clients might also remember the lack of DoQ support by     
  646    given IP addresses on a per-context basis (e.g., per network or         
  647    provisioning domain).                                                   
  649    Timeouts, connection refusals, and QUIC handshake failures are          
  650    indicators that a server does not support DoQ.  Clients SHOULD NOT      
  651    attempt DoQ queries to a server that does not support DoQ for a         
  652    reasonable period (such as one hour per server).  DNS clients           
  653    following an out-of-band key-pinned usage profile [RFC7858] MAY be      
  654    more aggressive about retrying after DoQ connection failures.           
  656 5.3.  Address Validation                                                   
  658    Section 8 of [RFC9000], the QUIC transport specification, defines       
  659    Address Validation procedures to avoid servers being used in address    
  660    amplification attacks.  DoQ implementations MUST conform to this        
  661    specification, which limits the worst-case amplification to a factor    
  662    3.                                                                      
  664    DoQ implementations SHOULD consider configuring servers to use the      
  665    Address Validation using Retry Packets procedure defined in             
  666    Section 8.1.2 of [RFC9000], the QUIC transport specification.  This     
  667    procedure imposes a 1-RTT delay for verifying the return routability    
  668    of the source address of a client, similar to the DNS Cookies           
  669    mechanism [RFC7873].                                                    
  671    DoQ implementations that configure Address Validation using Retry       
  672    Packets SHOULD implement the Address Validation for Future              
  673    Connections procedure defined in Section 8.1.3 of [RFC9000], the QUIC   
  674    transport specification.  This defines how servers can send NEW_TOKEN   
  675    frames to clients after the client address is validated in order to     
  676    avoid the 1-RTT penalty during subsequent connections by the client     
  677    from the same address.                                                  
  679 5.4.  Padding                                                              
  681    Implementations MUST protect against the traffic analysis attacks       
  682    described in Section 7.5 by the judicious injection of padding.  This   
  683    could be done either by padding individual DNS messages using the       
  684    EDNS(0) Padding Option [RFC7830] or by padding QUIC packets (see        
  685    Section 19.1 of [RFC9000]).                                             
  687    In theory, padding at the QUIC packet level could result in better      
  688    performance for the equivalent protection, because the amount of        
  689    padding can take into account non-DNS frames such as acknowledgements   
  690    or flow control updates, and also because QUIC packets can carry        
  691    multiple DNS messages.  However, applications can only control the      
  692    amount of padding in QUIC packets if the implementation of QUIC         
  693    exposes adequate APIs.  This leads to the following recommendations:    
  695    *  If the implementation of QUIC exposes APIs to set a padding          
  696       policy, DoQ SHOULD use that API to align the packet length to a      
  697       small set of fixed sizes.                                            
  699    *  If padding at the QUIC packet level is not available or not used,    
  700       DoQ MUST ensure that all DNS queries and responses are padded to a   
  701       small set of fixed sizes, using the EDNS(0) padding extension as     
  702       specified in [RFC7830].                                              
  704    Implementations might choose not to use a QUIC API for padding if it    
  705    is significantly simpler to reuse existing DNS message padding logic    
  706    that is applied to other encrypted transports.                          
  708    In the absence of a standard policy for padding sizes,                  
  709    implementations SHOULD follow the recommendations of the Experimental   
  710    status "Padding Policies for Extension Mechanisms for DNS (EDNS(0))"    
  711    [RFC8467].  While Experimental, these recommendations are referenced    
  712    because they are implemented and deployed for DoT and provide a way     
  713    for implementations to be fully compliant with this specification.      
  715 5.5.  Connection Handling                                                  
  717    "DNS Transport over TCP - Implementation Requirements" [RFC7766]        
  718    provides updated guidance on DNS over TCP, some of which is             
  719    applicable to DoQ.  This section provides similar advice on             
  720    connection handling for DoQ.                                            
  722 5.5.1.  Connection Reuse                                                   
  724    Historic implementations of DNS clients are known to open and close     
  725    TCP connections for each DNS query.  To amortize connection setup       
  726    costs, both clients and servers SHOULD support connection reuse by      
  727    sending multiple queries and responses over a single persistent QUIC    
  728    connection.                                                             
  730    In order to achieve performance on par with UDP, DNS clients SHOULD     
  731    send their queries concurrently over the QUIC streams on a QUIC         
  732    connection.  That is, when a DNS client sends multiple queries to a     
  733    server over a QUIC connection, it SHOULD NOT wait for an outstanding    
  734    reply before sending the next query.                                    
  736 5.5.2.  Resource Management                                                
  738    Proper management of established and idle connections is important to   
  739    the healthy operation of a DNS server.                                  
  741    An implementation of DoQ SHOULD follow best practices similar to        
  742    those specified for DNS over TCP [RFC7766], in particular with regard   
  743    to:                                                                     
  745    *  Concurrent Connections (Section 6.2.2 of [RFC7766], updated by       
  746       Section 6.4 of [RFC9103])                                            
  748    *  Security Considerations (Section 10 of [RFC7766])                    
  750    Failure to do so may lead to resource exhaustion and denial of          
  751    service.                                                                
  753    Clients that want to maintain long duration DoQ connections SHOULD      
  754    use the idle timeout mechanisms defined in Section 10.1 of [RFC9000],   
  755    the QUIC transport specification.  Clients and servers MUST NOT send    
  756    the edns-tcp-keepalive EDNS(0) Option [RFC7828] in any messages sent    
  757    on a DoQ connection (because it is specific to the use of TCP/TLS as    
  758    a transport).                                                           
  760    This document does not make specific recommendations for timeout        
  761    values on idle connections.  Clients and servers should reuse and/or    
  762    close connections depending on the level of available resources.        
  763    Timeouts may be longer during periods of low activity and shorter       
  764    during periods of high activity.                                        
  766 5.5.3.  Using 0-RTT and Session Resumption                                 
  768    Using 0-RTT for DoQ has many compelling advantages.  Clients can        
  769    establish connections and send queries without incurring a connection   
  770    delay.  Servers can thus negotiate low values of the connection         
  771    timers, which reduces the total number of connections that they need    
  772    to manage.  They can do that because the clients that use 0-RTT will    
  773    not incur latency penalties if new connections are required for a       
  774    query.                                                                  
  776    Session resumption and 0-RTT data transmission create privacy risks     
  777    detailed in Sections 7.1 and 7.2.  The following recommendations are    
  778    meant to reduce the privacy risks while enjoying the performance        
  779    benefits of 0-RTT data, subject to the restrictions specified in        
  780    Section 4.5.                                                            
  782    Clients SHOULD use resumption tickets only once, as specified in        
  783    Appendix C.4 of [RFC8446].  By default, clients SHOULD NOT use          
  784    session resumption if the client's connectivity has changed.            
  786    Clients could receive address validation tokens from the server using   
  787    the NEW_TOKEN mechanism; see Section 8 of [RFC9000].  The associated    
  788    tracking risks are mentioned in Section 7.3.  Clients SHOULD only use   
  789    the address validation tokens when they are also using session          
  790    resumption thus avoiding additional tracking risks.                     
  792    Servers SHOULD issue session resumption tickets with a sufficiently     
  793    long lifetime (e.g., 6 hours), so that clients are not tempted to       
  794    either keep the connection alive or frequently poll the server to       
  795    renew session resumption tickets.  Servers SHOULD implement the anti-   
  796    replay mechanisms specified in Section 8 of [RFC8446].                  
  798 5.5.4.  Controlling Connection Migration for Privacy                       
  800    DoQ implementations might consider using the connection migration       
  801    features defined in Section 9 of [RFC9000].  These features enable      
  802    connections to continue operating as the client's connectivity          
  803    changes.  As detailed in Section 7.4, these features trade off          
  804    privacy for latency.  By default, clients SHOULD be configured to       
  805    prioritize privacy and start new sessions if their connectivity         
  806    changes.                                                                
  808 5.6.  Processing Queries in Parallel                                       
  810    As specified in Section 7 of [RFC7766] "DNS Transport over TCP -        
  811    Implementation Requirements", resolvers are RECOMMENDED to support      
  812    the preparing of responses in parallel and sending them out of order.   
  813    In DoQ, they do that by sending responses on their specific stream as   
  814    soon as possible, without waiting for availability of responses for     
  815    previously opened streams.                                              
  817 5.7.  Zone Transfer                                                        
  819    [RFC9103] specifies zone transfer over TLS (XoT) and includes updates   
  820    to [RFC1995] (IXFR), [RFC5936] (AXFR), and [RFC7766].  Considerations   
  821    relating to the reuse of XoT connections described there apply          
  822    analogously to zone transfers performed using DoQ connections.  One     
  823    reason for reiterating such specific guidance is the lack of            
  824    effective connection reuse in existing TCP/TLS zone transfer            
  825    implementations today.  The following recommendations apply:            
  827    *  DoQ servers MUST be able to handle multiple concurrent IXFR          
  828       requests on a single QUIC connection.                                
  830    *  DoQ servers MUST be able to handle multiple concurrent AXFR          
  831       requests on a single QUIC connection.                                
  833    *  DoQ implementations SHOULD                                           
  835       -  use the same QUIC connection for both AXFR and IXFR requests to   
  836          the same primary                                                  
  838       -  send those requests in parallel as soon as they are queued,       
  839          i.e., do not wait for a response before sending the next query    
  840          on the connection (this is analogous to pipelining requests on    
  841          a TCP/TLS connection)                                             
  843       -  send the response(s) for each request as soon as they are         
  844          available, i.e., response streams MAY be sent intermingled        
  846 5.8.  Flow Control Mechanisms                                              
  848    Servers and clients manage flow control using the mechanisms defined    
  849    in Section 4 of [RFC9000].  These mechanisms allow clients and          
  850    servers to specify how many streams can be created, how much data can   
  851    be sent on a stream, and how much data can be sent on the union of      
  852    all streams.  For DoQ, controlling how many streams are created         
  853    allows servers to control how many new requests the client can send     
  854    on a given connection.                                                  
  856    Flow control exists to protect endpoint resources.  For servers,        
  857    global and per-stream flow control limits control how much data can     
  858    be sent by clients.  The same mechanisms allow clients to control how   
  859    much data can be sent by servers.  Values that are too small will       
  860    unnecessarily limit performance.  Values that are too large might       
  861    expose endpoints to overload or memory exhaustion.  Implementations     
  862    or deployments will need to adjust flow control limits to balance       
  863    these concerns.  In particular, zone transfer implementations will      
  864    need to control these limits carefully to ensure both large and         
  865    concurrent zone transfers are well managed.                             
  867    Initial values of parameters control how many requests and how much     
  868    data can be sent by clients and servers at the beginning of the         
  869    connection.  These values are specified in transport parameters         
  870    exchanged during the connection handshake.  The parameter values        
  871    received in the initial connection also control how many requests and   
  872    how much data can be sent by clients using 0-RTT data in a resumed      
  873    connection.  Using too small values of these initial parameters would   
  874    restrict the usefulness of allowing 0-RTT data.                         
  876 6.  Security Considerations                                                
  878    A Threat Analysis of the Domain Name System is found in [RFC3833].      
  879    This analysis was written before the development of DoT, DoH, and       
  880    DoQ, and probably needs to be updated.                                  
  882    The security considerations of DoQ should be comparable to those of     
  883    DoT [RFC7858].  DoT as specified in [RFC7858] only addresses the stub   
  884    to recursive scenario, but the considerations about person-in-the-      
  885    middle attacks, middleboxes, and caching of data from cleartext         
  886    connections also apply for DoQ to the resolver to authoritative         
  887    server scenario.  As stated in Section 5.1, the authentication          
  888    requirements for securing zone transfer using DoQ are the same as       
  889    those for zone transfer over DoT; therefore, the general security       
  890    considerations are entirely analogous to those described in             
  891    [RFC9103].                                                              
  893    DoQ relies on QUIC, which itself relies on TLS 1.3 and thus supports    
  894    by default the protections against downgrade attacks described in       
  895    [BCP195].  QUIC-specific issues and their mitigations are described     
  896    in Section 21 of [RFC9000].                                             
  898 7.  Privacy Considerations                                                 
  900    The general considerations of encrypted transports provided in "DNS     
  901    Privacy Considerations" [RFC9076] apply to DoQ.  The specific           
  902    considerations provided there do not differ between DoT and DoQ, and    
  903    they are not discussed further here.  Similarly, "Recommendations for   
  904    DNS Privacy Service Operators" [RFC8932] (which covers operational,     
  905    policy, and security considerations for DNS privacy services) is also   
  906    applicable to DoQ services.                                             
  908    QUIC incorporates the mechanisms of TLS 1.3 [RFC8446], and this         
  909    enables QUIC transmission of "0-RTT" data.  This can provide            
  910    interesting latency gains, but it raises two concerns:                  
  912    1.  Adversaries could replay the 0-RTT data and infer its content       
  913        from the behavior of the receiving server.                          
  915    2.  The 0-RTT mechanism relies on TLS session resumption, which can     
  916        provide linkability between successive client sessions.             
  918    These issues are developed in Sections 7.1 and 7.2.                     
  920 7.1.  Privacy Issues with 0-RTT data                                       
  922    The 0-RTT data can be replayed by adversaries.  That data may trigger   
  923    queries by a recursive resolver to authoritative resolvers.             
  924    Adversaries may be able to pick a time at which the recursive           
  925    resolver outgoing traffic is observable and thus find out what name     
  926    was queried for in the 0-RTT data.                                      
  928    This risk is in fact a subset of the general problem of observing the   
  929    behavior of the recursive resolver discussed in "DNS Privacy            
  930    Considerations" [RFC9076].  The attack is partially mitigated by        
  931    reducing the observability of this traffic.  The mandatory replay       
  932    protection mechanisms in TLS 1.3 [RFC8446] limit but do not eliminate   
  933    the risk of replay. 0-RTT packets can only be replayed within a         
  934    narrow window, which is only wide enough to account for variations in   
  935    clock skew and network transmission.                                    
  937    The recommendation for TLS 1.3 [RFC8446] is that the capability to      
  938    use 0-RTT data should be turned off by default and only enabled if      
  939    the user clearly understands the associated risks.  In the case of      
  940    DoQ, allowing 0-RTT data provides significant performance gains, and    
  941    there is a concern that a recommendation to not use it would simply     
  942    be ignored.  Instead, a set of practical recommendations is provided    
  943    in Sections 4.5 and 5.5.3.                                              
  945    The specifications in Section 4.5 block the most obvious risks of       
  946    replay attacks, as they only allow for transactions that will not       
  947    change the long-term state of the server.                               
  949    The attacks described above apply to the stub resolver to recursive     
  950    resolver scenario, but similar attacks might be envisaged in the        
  951    recursive resolver to authoritative resolver scenario, and the same     
  952    mitigations apply.                                                      
  954 7.2.  Privacy Issues with Session Resumption                               
  956    The QUIC session resumption mechanism reduces the cost of re-           
  957    establishing sessions and enables 0-RTT data.  There is a linkability   
  958    issue associated with session resumption, if the same resumption        
  959    token is used several times.  Attackers on path between client and      
  960    server could observe repeated usage of the token and use that to        
  961    track the client over time or over multiple locations.                  
  963    The session resumption mechanism allows servers to correlate the        
  964    resumed sessions with the initial sessions and thus to track the        
  965    client.  This creates a virtual long duration session.  The series of   
  966    queries in that session can be used by the server to identify the       
  967    client.  Servers can most probably do that already if the client        
  968    address remains constant, but session resumption tickets also enable    
  969    tracking after changes of the client's address.                         
  971    The recommendations in Section 5.5.3 are designed to mitigate these     
  972    risks.  Using session tickets only once mitigates the risk of           
  973    tracking by third parties.  Refusing to resume a session if addresses   
  974    change mitigates the incremental risk of tracking by the server (but    
  975    the risk of tracking by IP address remains).                            
  977    The privacy trade-offs here may be context specific.  Stub resolvers    
  978    will have a strong motivation to prefer privacy over latency since      
  979    they often change location.  However, recursive resolvers that use a    
  980    small set of static IP addresses are more likely to prefer the          
  981    reduced latency provided by session resumption and may consider this    
  982    a valid reason to use resumption tickets even if the IP address         
  983    changed between sessions.                                               
  985    Encrypted zone transfer ([RFC9103]) explicitly does not attempt to      
  986    hide the identity of the parties involved in the transfer; at the       
  987    same time, such transfers are not particularly latency sensitive.       
  988    This means that applications supporting zone transfers may decide to    
  989    apply the same protections as stub to recursive applications.           
  991 7.3.  Privacy Issues with Address Validation Tokens                        
  993    QUIC specifies address validation mechanisms in Section 8 of            
  994    [RFC9000].  Use of an address validation token allows QUIC servers to   
  995    avoid an extra RTT for new connections.  Address validation tokens      
  996    are typically tied to an IP address.  QUIC clients normally only use    
  997    these tokens when setting up a new connection from a previously used    
  998    address.  However, clients are not always aware that they are using a   
  999    new address.  This could be due to NAT, or because the client does      
 1000    not have an API available to check if the IP address has changed        
 1001    (which can be quite often for IPv6).  There is a linkability risk if    
 1002    clients mistakenly use address validation tokens after unknowingly      
 1003    moving to a new location.                                               
 1005    The recommendations in Section 5.5.3 mitigates this risk by tying the   
 1006    usage of the NEW_TOKEN to that of session resumption, though this       
 1007    recommendation does not cover the case where the client is unaware of   
 1008    the address change.                                                     
 1010 7.4.  Privacy Issues with Long Duration Sessions                           
 1012    A potential alternative to session resumption is the use of long        
 1013    duration sessions: if a session remains open for a long time, new       
 1014    queries can be sent without incurring connection establishment          
 1015    delays.  It is worth pointing out that the two solutions have similar   
 1016    privacy characteristics.  Session resumption may allow servers to       
 1017    keep track of the IP addresses of clients, but long duration sessions   
 1018    have the same effect.                                                   
 1020    In particular, a DoQ implementation might take advantage of the         
 1021    connection migration features of QUIC to maintain a session even if     
 1022    the client's connectivity changes, for example, if the client           
 1023    migrates from a Wi-Fi connection to a cellular network connection and   
 1024    then to another Wi-Fi connection.  The server would be able to track    
 1025    the client location by monitoring the succession of IP addresses used   
 1026    by the long duration connection.                                        
 1028    The recommendation in Section 5.5.4 mitigates the privacy concerns      
 1029    related to long duration sessions using multiple client addresses.      
 1031 7.5.  Traffic Analysis                                                     
 1033    Even though QUIC packets are encrypted, adversaries can gain            
 1034    information from observing packet lengths, in both queries and          
 1035    responses, as well as packet timing.  Many DNS requests are emitted     
 1036    by web browsers.  Loading a specific web page may require resolving     
 1037    dozens of DNS names.  If an application adopts a simple mapping of      
 1038    one query or response per packet, or "one QUIC STREAM frame per         
 1039    packet", then the succession of packet lengths may provide enough       
 1040    information to identify the requested site.                             
 1042    Implementations SHOULD use the mechanisms defined in Section 5.4 to     
 1043    mitigate this attack.                                                   
 1045 8.  IANA Considerations                                                    
 1047 8.1.  Registration of a DoQ Identification String                          
 1049    This document creates a new registration for the identification of      
 1050    DoQ in the "TLS Application-Layer Protocol Negotiation (ALPN)           
 1051    Protocol IDs" registry [RFC7301].                                       
 1053    The "doq" string identifies DoQ:                                        
 1055    Protocol:  DoQ                                                          
 1057    Identification Sequence:  0x64 0x6F 0x71 ("doq")                        
 1059    Specification:  This document                                           
 1061 8.2.  Reservation of a Dedicated Port                                      
 1063    For both TCP and UDP, port 853 is currently reserved for "DNS query-    
 1064    response protocol run over TLS/DTLS" [RFC7858].                         
 1066    However, the specification for DNS over DTLS (DoD) [RFC8094] is         
 1067    experimental, limited to stub to resolver, and no implementations or    
 1068    deployments currently exist to the authors' knowledge (even though      
 1069    several years have passed since the specification was published).       
 1071    This specification additionally reserves the use of UDP port 853 for    
 1072    DoQ.  QUIC version 1 was designed to be able to coexist with other      
 1073    protocols on the same port, including DTLS; see Section 17.2 of         
 1074    [RFC9000].  This means that deployments that serve DoD and DoQ (QUIC    
 1075    version 1) on the same port will be able to demultiplex the two due     
 1076    to the second most significant bit in each UDP payload.  Such           
 1077    deployments ought to check the signatures of future versions or         
 1078    extensions (e.g., [GREASING-QUIC]) of QUIC and DTLS before deploying    
 1079    them to serve DNS on the same port.                                     
 1081    IANA has updated the following value in the "Service Name and           
 1082    Transport Protocol Port Number Registry" in the System range.  The      
 1083    registry for that range requires IETF Review or IESG Approval           
 1084    [RFC6335].                                                              
 1086    Service Name:  domain-s                                                 
 1088    Port Number:  853                                                       
 1090    Transport Protocol(s):  UDP                                             
 1092    Assignee:  IESG                                                         
 1094    Contact:  IETF Chair                                                    
 1096    Description:  DNS query-response protocol run over DTLS or QUIC         
 1098    Reference:  [RFC7858][RFC8094] This document                            
 1100    Additionally, IANA has updated the Description field for the            
 1101    corresponding TCP port 853 allocation to be "DNS query-response         
 1102    protocol run over TLS" and removed [RFC8094] from the TCP               
 1103    allocation's Reference field for consistency and clarity.               
 1105 8.3.  Reservation of an Extended DNS Error Code: Too Early                 
 1107    IANA has registered the following value in the "Extended DNS Error      
 1108    Codes" registry [RFC8914]:                                              
 1110    INFO-CODE:  26                                                          
 1112    Purpose:  Too Early                                                     
 1114    Reference:  This document                                               
 1116 8.4.  DNS-over-QUIC Error Codes Registry                                   
 1118    IANA has added a registry for "DNS-over-QUIC Error Codes" on the        
 1119    "Domain Name System (DNS) Parameters" web page.                         
 1121    The "DNS-over-QUIC Error Codes" registry governs a 62-bit space.        
 1122    This space is split into three regions that are governed by different   
 1123    policies:                                                               
 1125    *  Permanent registrations for values between 0x00 and 0x3f (in         
 1126       hexadecimal; inclusive), which are assigned using Standards Action   
 1127       or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126]    
 1129    *  Permanent registrations for values larger than 0x3f, which are       
 1130       assigned using the Specification Required policy ([RFC8126])         
 1132    *  Provisional registrations for values larger than 0x3f, which         
 1133       require Expert Review, as defined in Section 4.5 of [RFC8126].       
 1135    Provisional reservations share the range of values larger than 0x3f     
 1136    with some permanent registrations.  This is by design to enable         
 1137    conversion of provisional registrations into permanent registrations    
 1138    without requiring changes in deployed systems.  (This design is         
 1139    aligned with the principles set in Section 22 of [RFC9000].)            
 1141    Registrations in this registry MUST include the following fields:       
 1143    Value:  The assigned codepoint                                          
 1145    Status:  "Permanent" or "Provisional"                                   
 1147    Contact:  Contact details for the registrant                            
 1149    In addition, permanent registrations MUST include:                      
 1151    Error:  A short mnemonic for the parameter                              
 1153    Specification:  A reference to a publicly available specification for   
 1154       the value (optional for provisional registrations)                   
 1156    Description:  A brief description of the error code semantics, which    
 1157       MAY be a summary if a specification reference is provided            
 1159    Provisional registrations of codepoints are intended to allow for       
 1160    private use and experimentation with extensions to DoQ.  However,       
 1161    provisional registrations could be reclaimed and reassigned for other   
 1162    purposes.  In addition to the parameters listed above, provisional      
 1163    registrations MUST include:                                             
 1165    Date:  The date of last update to the registration                      
 1167    A request to update the date on any provisional registration can be     
 1168    made without review from the designated expert(s).                      
 1170    The initial content of this registry is shown in Table 1 and all        
 1171    entries share the following fields:                                     
 1173    Status:  Permanent                                                      
 1175    Contact:  DPRIVE WG                                                     
 1177    Specification:  Section 4.3                                             
 1179    +============+=======================+=============================+    
 1180    | Value      | Error                 | Description                 |    
 1181    +============+=======================+=============================+    
 1182    | 0x0        | DOQ_NO_ERROR          | No error                    |    
 1183    +------------+-----------------------+-----------------------------+    
 1184    | 0x1        | DOQ_INTERNAL_ERROR    | Implementation error        |    
 1185    +------------+-----------------------+-----------------------------+    
 1186    | 0x2        | DOQ_PROTOCOL_ERROR    | Generic protocol violation  |    
 1187    +------------+-----------------------+-----------------------------+    
 1188    | 0x3        | DOQ_REQUEST_CANCELLED | Request cancelled by client |    
 1189    +------------+-----------------------+-----------------------------+    
 1190    | 0x4        | DOQ_EXCESSIVE_LOAD    | Closing a connection for    |    
 1191    |            |                       | excessive load              |    
 1192    +------------+-----------------------+-----------------------------+    
 1193    | 0x5        | DOQ_UNSPECIFIED_ERROR | No error reason specified   |    
 1194    +------------+-----------------------+-----------------------------+    
 1195    | 0xd098ea5e | DOQ_ERROR_RESERVED    | Alternative error code used |    
 1196    |            |                       | for tests                   |    
 1197    +------------+-----------------------+-----------------------------+    
 1199             Table 1: Initial DNS-over-QUIC Error Codes Entries             
 1201 9.  References                                                             
 1203 9.1.  Normative References                                                 
 1205    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",   
 1206               STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,       
 1207               <https://www.rfc-editor.org/info/rfc1034>.                   
 1209    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
 1210               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,      
 1211               November 1987, <https://www.rfc-editor.org/info/rfc1035>.    
 1213    [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,      
 1214               DOI 10.17487/RFC1995, August 1996,                           
 1215               <https://www.rfc-editor.org/info/rfc1995>.                   
 1217    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
 1218               Requirement Levels", BCP 14, RFC 2119,                       
 1219               DOI 10.17487/RFC2119, March 1997,                            
 1220               <https://www.rfc-editor.org/info/rfc2119>.                   
 1222    [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol    
 1223               (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,          
 1224               <https://www.rfc-editor.org/info/rfc5936>.                   
 1226    [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms    
 1227               for DNS (EDNS(0))", STD 75, RFC 6891,                        
 1228               DOI 10.17487/RFC6891, April 2013,                            
 1229               <https://www.rfc-editor.org/info/rfc6891>.                   
 1231    [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,          
 1232               "Transport Layer Security (TLS) Application-Layer Protocol   
 1233               Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,      
 1234               July 2014, <https://www.rfc-editor.org/info/rfc7301>.        
 1236    [RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and    
 1237               D. Wessels, "DNS Transport over TCP - Implementation         
 1238               Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,   
 1239               <https://www.rfc-editor.org/info/rfc7766>.                   
 1241    [RFC7830]  Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,       
 1242               DOI 10.17487/RFC7830, May 2016,                              
 1243               <https://www.rfc-editor.org/info/rfc7830>.                   
 1245    [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,     
 1246               and P. Hoffman, "Specification for DNS over Transport        
 1247               Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May   
 1248               2016, <https://www.rfc-editor.org/info/rfc7858>.             
 1250    [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for        
 1251               Writing an IANA Considerations Section in RFCs", BCP 26,     
 1252               RFC 8126, DOI 10.17487/RFC8126, June 2017,                   
 1253               <https://www.rfc-editor.org/info/rfc8126>.                   
 1255    [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC       
 1256               2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,     
 1257               May 2017, <https://www.rfc-editor.org/info/rfc8174>.         
 1259    [RFC8310]  Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles    
 1260               for DNS over TLS and DNS over DTLS", RFC 8310,               
 1261               DOI 10.17487/RFC8310, March 2018,                            
 1262               <https://www.rfc-editor.org/info/rfc8310>.                   
 1264    [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol   
 1265               Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,   
 1266               <https://www.rfc-editor.org/info/rfc8446>.                   
 1268    [RFC8467]  Mayrhofer, A., "Padding Policies for Extension Mechanisms    
 1269               for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,          
 1270               October 2018, <https://www.rfc-editor.org/info/rfc8467>.     
 1272    [RFC8914]  Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.       
 1273               Lawrence, "Extended DNS Errors", RFC 8914,                   
 1274               DOI 10.17487/RFC8914, October 2020,                          
 1275               <https://www.rfc-editor.org/info/rfc8914>.                   
 1277    [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based     
 1278               Multiplexed and Secure Transport", RFC 9000,                 
 1279               DOI 10.17487/RFC9000, May 2021,                              
 1280               <https://www.rfc-editor.org/info/rfc9000>.                   
 1282    [RFC9001]  Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure    
 1283               QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,             
 1284               <https://www.rfc-editor.org/info/rfc9001>.                   
 1286    [RFC9103]  Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A.       
 1287               Mankin, "DNS Zone Transfer over TLS", RFC 9103,              
 1288               DOI 10.17487/RFC9103, August 2021,                           
 1289               <https://www.rfc-editor.org/info/rfc9103>.                   
 1291 9.2.  Informative References                                               
 1293    [BCP195]   Sheffer, Y., Holz, R., and P. Saint-Andre,                   
 1294               "Recommendations for Secure Use of Transport Layer           
 1295               Security (TLS) and Datagram Transport Layer Security         
 1296               (DTLS)", BCP 195, RFC 7525, May 2015.                        
 1298               Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS    
 1299               1.1", BCP 195, RFC 8996, March 2021.                         
 1301               <https://www.rfc-editor.org/info/bcp195>                     
 1303    [DNS-TERMS]                                                             
 1304               Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in      
 1305               Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-03,    
 1306               28 September 2021, <https://datatracker.ietf.org/doc/html/   
 1307               draft-ietf-dnsop-rfc8499bis-03>.                             
 1309    [DNS0RTT]  Kahn Gillmor, D., "DNS + 0-RTT", Message to DNS-Privacy WG   
 1310               mailing list, 6 April 2016, <https://www.ietf.org/mail-      
 1311               archive/web/dns-privacy/current/msg01276.html>.              
 1313    [GREASING-QUIC]                                                         
 1314               Thomson, M., "Greasing the QUIC Bit", Work in Progress,      
 1315               Internet-Draft, draft-ietf-quic-bit-grease-02, 10 November   
 1316               2021, <https://datatracker.ietf.org/doc/html/draft-ietf-     
 1317               quic-bit-grease-02>.                                         
 1319    [HTTP/3]   Bishop, M., Ed., "Hypertext Transfer Protocol Version 3      
 1320               (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-     
 1321               quic-http-34, 2 February 2021,                               
 1322               <https://datatracker.ietf.org/doc/html/draft-ietf-quic-      
 1323               http-34>.                                                    
 1325    [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone      
 1326               Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,       
 1327               August 1996, <https://www.rfc-editor.org/info/rfc1996>.      
 1329    [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain    
 1330               Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August   
 1331               2004, <https://www.rfc-editor.org/info/rfc3833>.             
 1333    [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.    
 1334               Cheshire, "Internet Assigned Numbers Authority (IANA)        
 1335               Procedures for the Management of the Service Name and        
 1336               Transport Protocol Port Number Registry", BCP 165,           
 1337               RFC 6335, DOI 10.17487/RFC6335, August 2011,                 
 1338               <https://www.rfc-editor.org/info/rfc6335>.                   
 1340    [RFC7828]  Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The   
 1341               edns-tcp-keepalive EDNS0 Option", RFC 7828,                  
 1342               DOI 10.17487/RFC7828, April 2016,                            
 1343               <https://www.rfc-editor.org/info/rfc7828>.                   
 1345    [RFC7873]  Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)   
 1346               Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,          
 1347               <https://www.rfc-editor.org/info/rfc7873>.                   
 1349    [RFC8094]  Reddy, T., Wing, D., and P. Patil, "DNS over Datagram        
 1350               Transport Layer Security (DTLS)", RFC 8094,                  
 1351               DOI 10.17487/RFC8094, February 2017,                         
 1352               <https://www.rfc-editor.org/info/rfc8094>.                   
 1354    [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS          
 1355               (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,        
 1356               <https://www.rfc-editor.org/info/rfc8484>.                   
 1358    [RFC8490]  Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,      
 1359               Lemon, T., and T. Pusateri, "DNS Stateful Operations",       
 1360               RFC 8490, DOI 10.17487/RFC8490, March 2019,                  
 1361               <https://www.rfc-editor.org/info/rfc8490>.                   
 1363    [RFC8932]  Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and    
 1364               A. Mankin, "Recommendations for DNS Privacy Service          
 1365               Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932,         
 1366               October 2020, <https://www.rfc-editor.org/info/rfc8932>.     
 1368    [RFC9002]  Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection     
 1369               and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,     
 1370               May 2021, <https://www.rfc-editor.org/info/rfc9002>.         
 1372    [RFC9076]  Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076,   
 1373               DOI 10.17487/RFC9076, July 2021,                             
 1374               <https://www.rfc-editor.org/info/rfc9076>.                   
 1376 Appendix A.  The NOTIFY Service                                            
 1378    This appendix discusses why it is considered acceptable to send         
 1379    NOTIFY (see [RFC1996]) in 0-RTT data.                                   
 1381    Section 4.5 says "The 0-RTT mechanism MUST NOT be used to send DNS      
 1382    requests that are not "replayable" transactions".  This specification   
 1383    supports sending a NOTIFY in 0-RTT data because although a NOTIFY       
 1384    technically changes the state of the receiving server, the effect of    
 1385    replaying NOTIFYs has negligible impact in practice.                    
 1387    NOTIFY messages prompt a secondary to either send an SOA query or an    
 1388    XFR request to the primary on the basis that a newer version of the     
 1389    zone is available.  It has long been recognized that NOTIFYs can be     
 1390    forged and, in theory, used to cause a secondary to send repeated       
 1391    unnecessary requests to the primary.  For this reason, most             
 1392    implementations have some form of throttling of the SOA/XFR queries     
 1393    triggered by the receipt of one or more NOTIFYs.                        
 1395    [RFC9103] describes the privacy risks associated with both NOTIFY and   
 1396    SOA queries and does not include addressing those risks within the      
 1397    scope of encrypting zone transfers.  Given this, the privacy benefit    
 1398    of using DoQ for NOTIFY is not clear, but for the same reason,          
 1399    sending NOTIFY as 0-RTT data has no privacy risk above that of          
 1400    sending it using cleartext DNS.                                         
 1402 Acknowledgements                                                           
 1404    This document liberally borrows text from the HTTP/3 specification      
 1405    [HTTP/3] edited by Mike Bishop and from the DoT specification           
 1406    [RFC7858] authored by Zi Hu, Liang Zhu, John Heidemann, Allison         
 1407    Mankin, Duane Wessels, and Paul Hoffman.                                
 1409    The privacy issue with 0-RTT data and session resumption was analyzed   
 1410    by Daniel Kahn Gillmor (DKG) in a message to the IETF DPRIVE Working    
 1411    Group [DNS0RTT].                                                        
 1413    Thanks to Tony Finch for an extensive review of the initial draft       
 1414    version of this document, and to Robert Evans for the discussion of     
 1415    0-RTT privacy issues.  Early reviews by Paul Hoffman and Martin         
 1416    Thomson and interoperability tests conducted by Stephane Bortzmeyer     
 1417    helped improve the definition of the protocol.                          
 1419    Thanks also to Martin Thomson and Martin Duke for their later reviews   
 1420    focusing on the low-level QUIC details, which helped clarify several    
 1421    aspects of DoQ.  Thanks to Andrey Meshkov, Loganaden Velvindron,        
 1422    Lucas Pardue, Matt Joras, Mirja Kuelewind, Brian Trammell, and          
 1423    Phillip Hallam-Baker for their reviews and contributions.               
 1425 Authors' Addresses                                                         
 1427    Christian Huitema                                                       
 1428    Private Octopus Inc.                                                    
 1429    427 Golfcourse Rd                                                       
 1430    Friday Harbor,  WA 98250                                                
 1431    United States of America                                                
 1432    Email: huitema@huitema.net                                              
 1435    Sara Dickinson                                                          
 1436    Sinodun IT                                                              
 1437    Oxford Science Park                                                     
 1438    Oxford                                                                  
 1439    OX4 4GA                                                                 
 1440    United Kingdom                                                          
 1441    Email: sara@sinodun.com                                                 
 1444    Allison Mankin                                                          
 1445    Salesforce                                                              
 1446    Email: allison.mankin@gmail.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.