1 Internet Engineering Task Force (IETF)                       B. Schwartz   
    2 Request for Comments: 9460                          Meta Platforms, Inc.   
    3 Category: Standards Track                                      M. Bishop   
    4 ISSN: 2070-1721                                                E. Nygren   
    5                                                      Akamai Technologies   
    6                                                            November 2023   
    7                                                                            
    8                                                                            
    9 Service Binding and Parameter Specification via the DNS (SVCB and HTTPS    
   10                            Resource Records)                               
   11                                                                            
   12 Abstract                                                                   
   13                                                                            
   14    This document specifies the "SVCB" ("Service Binding") and "HTTPS"      
   15    DNS resource record (RR) types to facilitate the lookup of              
   16    information needed to make connections to network services, such as     
   17    for HTTP origins.  SVCB records allow a service to be provided from     
   18    multiple alternative endpoints, each with associated parameters (such   
   19    as transport protocol configuration), and are extensible to support     
   20    future uses (such as keys for encrypting the TLS ClientHello).  They    
   21    also enable aliasing of apex domains, which is not possible with        
   22    CNAME.  The HTTPS RR is a variation of SVCB for use with HTTP (see      
   23    RFC 9110, "HTTP Semantics").  By providing more information to the      
   24    client before it attempts to establish a connection, these records      
   25    offer potential benefits to both performance and privacy.               
   26                                                                            
   27 Status of This Memo                                                        
   28                                                                            
   29    This is an Internet Standards Track document.                           
   30                                                                            
   31    This document is a product of the Internet Engineering Task Force       
   32    (IETF).  It represents the consensus of the IETF community.  It has     
   33    received public review and has been approved for publication by the     
   34    Internet Engineering Steering Group (IESG).  Further information on     
   35    Internet Standards is available in Section 2 of RFC 7841.               
   36                                                                            
   37    Information about the current status of this document, any errata,      
   38    and how to provide feedback on it may be obtained at                    
   39    https://www.rfc-editor.org/info/rfc9460.                                
   40                                                                            
   41 Copyright Notice                                                           
   42                                                                            
   43    Copyright (c) 2023 IETF Trust and the persons identified as the         
   44    document authors.  All rights reserved.                                 
   45                                                                            
   46    This document is subject to BCP 78 and the IETF Trust's Legal           
   47    Provisions Relating to IETF Documents                                   
   48    (https://trustee.ietf.org/license-info) in effect on the date of        
   49    publication of this document.  Please review these documents            
   50    carefully, as they describe your rights and restrictions with respect   
   51    to this document.  Code Components extracted from this document must    
   52    include Revised BSD License text as described in Section 4.e of the     
   53    Trust Legal Provisions and are provided without warranty as described   
   54    in the Revised BSD License.                                             
   55                                                                            
   56 Table of Contents                                                          
   57                                                                            
   58    1.  Introduction                                                        
   59      1.1.  Goals                                                           
   60      1.2.  Overview of the SVCB RR                                         
   61      1.3.  Terminology                                                     
   62    2.  The SVCB Record Type                                                
   63      2.1.  Zone-File Presentation Format                                   
   64      2.2.  RDATA Wire Format                                               
   65      2.3.  SVCB Query Names                                                
   66      2.4.  Interpretation                                                  
   67        2.4.1.  SvcPriority                                                 
   68        2.4.2.  AliasMode                                                   
   69        2.4.3.  ServiceMode                                                 
   70      2.5.  Special Handling of "." in TargetName                           
   71        2.5.1.  AliasMode                                                   
   72        2.5.2.  ServiceMode                                                 
   73    3.  Client Behavior                                                     
   74      3.1.  Handling Resolution Failures                                    
   75      3.2.  Clients Using a Proxy                                           
   76    4.  DNS Server Behavior                                                 
   77      4.1.  Authoritative Servers                                           
   78      4.2.  Recursive Resolvers                                             
   79        4.2.1.  DNS64                                                       
   80      4.3.  General Requirements                                            
   81      4.4.  EDNS Client Subnet (ECS)                                        
   82    5.  Performance Optimizations                                           
   83      5.1.  Optimistic Pre-connection and Connection Reuse                  
   84      5.2.  Generating and Using Incomplete Responses                       
   85    6.  SVCB-Compatible RR Types                                            
   86    7.  Initial SvcParamKeys                                                
   87      7.1.  "alpn" and "no-default-alpn"                                    
   88        7.1.1.  Representation                                              
   89        7.1.2.  Use                                                         
   90      7.2.  "port"                                                          
   91      7.3.  "ipv4hint" and "ipv6hint"                                       
   92      7.4.  "mandatory"                                                     
   93    8.  ServiceMode RR Compatibility and Mandatory Keys                     
   94    9.  Using Service Bindings with HTTP                                    
   95      9.1.  Query Names for HTTPS RRs                                       
   96      9.2.  Comparison with Alt-Svc                                         
   97        9.2.1.  ALPN Usage                                                  
   98        9.2.2.  Untrusted Channels                                          
   99        9.2.3.  Cache Lifetime                                              
  100        9.2.4.  Granularity                                                 
  101      9.3.  Interaction with Alt-Svc                                        
  102      9.4.  Requiring Server Name Indication                                
  103      9.5.  HTTP Strict Transport Security (HSTS)                           
  104      9.6.  Use of HTTPS RRs in Other Protocols                             
  105    10. Zone Structures                                                     
  106      10.1.  Structuring Zones for Flexibility                              
  107      10.2.  Structuring Zones for Performance                              
  108      10.3.  Operational Considerations                                     
  109      10.4.  Examples                                                       
  110        10.4.1.  Protocol Enhancements                                      
  111        10.4.2.  Apex Aliasing                                              
  112        10.4.3.  Parameter Binding                                          
  113        10.4.4.  Multi-CDN Configuration                                    
  114        10.4.5.  Non-HTTP Uses                                              
  115    11. Interaction with Other Standards                                    
  116    12. Security Considerations                                             
  117    13. Privacy Considerations                                              
  118    14. IANA Considerations                                                 
  119      14.1.  SVCB RR Type                                                   
  120      14.2.  HTTPS RR Type                                                  
  121      14.3.  New Registry for Service Parameters                            
  122        14.3.1.  Procedure                                                  
  123        14.3.2.  Initial Contents                                           
  124      14.4.  Other Registry Updates                                         
  125    15. References                                                          
  126      15.1.  Normative References                                           
  127      15.2.  Informative References                                         
  128    Appendix A.  Decoding Text in Zone Files                                
  129      A.1.  Decoding a Comma-Separated List                                 
  130    Appendix B.  HTTP Mapping Summary                                       
  131    Appendix C.  Comparison with Alternatives                               
  132      C.1.  Differences from the SRV RR Type                                
  133      C.2.  Differences from the Proposed HTTP Record                       
  134      C.3.  Differences from the Proposed ANAME Record                      
  135      C.4.  Comparison with Separate RR Types for AliasMode and             
  136            ServiceMode                                                     
  137    Appendix D.  Test Vectors                                               
  138      D.1.  AliasMode                                                       
  139      D.2.  ServiceMode                                                     
  140      D.3.  Failure Cases                                                   
  141    Acknowledgments and Related Proposals                                   
  142    Authors' Addresses                                                      
  143                                                                            
  144 1.  Introduction                                                           
  145                                                                            
  146    The SVCB ("Service Binding") and HTTPS resource records (RRs) provide   
  147    clients with complete instructions for access to a service.  This       
  148    information enables improved performance and privacy by avoiding        
  149    transient connections to a suboptimal default server, negotiating a     
  150    preferred protocol, and providing relevant public keys.                 
  151                                                                            
  152    For example, HTTP clients currently resolve only A and/or AAAA          
  153    records for the origin hostname, learning only its IP addresses.  If    
  154    an HTTP client learns more about the origin before connecting, it may   
  155    be able to upgrade "http" URLs to "https", enable HTTP/3 or Encrypted   
  156    ClientHello [ECH], or switch to an operationally preferable endpoint.   
  157    It is highly desirable to minimize the number of round trips and        
  158    lookups required to learn this additional information.                  
  159                                                                            
  160    The SVCB and HTTPS RRs also help when the operator of a service         
  161    wishes to delegate operational control to one or more other domains,    
  162    e.g., aliasing the origin "https://example.com" to a service operator   
  163    endpoint at "svc.example.net".  While this case can sometimes be        
  164    handled by a CNAME, that does not cover all use cases.  CNAME is also   
  165    inadequate when the service operator needs to provide a bound           
  166    collection of consistent configuration parameters through the DNS       
  167    (such as network location, protocol, and keying information).           
  168                                                                            
  169    This document first describes the SVCB RR as a general-purpose RR       
  170    that can be applied directly and efficiently to a wide range of         
  171    services (Section 2).  It also describes the rules for defining other   
  172    SVCB-compatible RR types (Section 6), starting with the HTTPS RR type   
  173    (Section 9), which provides improved efficiency and convenience with    
  174    HTTP by avoiding the need for an Attrleaf label [Attrleaf]              
  175    (Section 9.1).                                                          
  176                                                                            
  177    The SVCB RR has two modes: 1) "AliasMode", which simply delegates       
  178    operational control for a resource and 2) "ServiceMode", which binds    
  179    together configuration information for a service endpoint.              
  180    ServiceMode provides additional key=value parameters within each        
  181    RDATA set.                                                              
  182                                                                            
  183 1.1.  Goals                                                                
  184                                                                            
  185    The goal of the SVCB RR is to allow clients to resolve a single         
  186    additional DNS RR in a way that:                                        
  187                                                                            
  188    *  Provides alternative endpoints that are authoritative for the        
  189       service, along with parameters associated with each of these         
  190       endpoints.                                                           
  191                                                                            
  192    *  Does not assume that all alternative endpoints have the same         
  193       parameters or capabilities, or are even operated by the same         
  194       entity.  This is important, as DNS does not provide any way to tie   
  195       together multiple RRsets for the same name.  For example, if         
  196       "www.example.com" is a CNAME alias that switches between one of      
  197       three Content Delivery Networks (CDNs) or hosting environments,      
  198       successive queries for that name may return records that             
  199       correspond to different environments.                                
  200                                                                            
  201    *  Enables CNAME-like functionality at a zone apex (such as             
  202       "example.com") for participating protocols and generally enables     
  203       extending operational authority for a service identified by a        
  204       domain name to other instances with alternate names.                 
  205                                                                            
  206    Additional goals specific to HTTPS RRs and the HTTP use cases           
  207    include:                                                                
  208                                                                            
  209    *  Connecting directly to HTTP/3 (QUIC transport) alternative           
  210       endpoints [HTTP/3].                                                  
  211                                                                            
  212    *  Supporting non-default TCP and UDP ports.                            
  213                                                                            
  214    *  Enabling SRV-like benefits (e.g., apex aliasing, as mentioned        
  215       above) for HTTP, where SRV [SRV] has not been widely adopted.        
  216                                                                            
  217    *  Providing an indication signaling that the "https" scheme should     
  218       be used instead of "http" for all HTTP requests to this host and     
  219       port, similar to HTTP Strict Transport Security [HSTS] (see          
  220       Section 9.5).                                                        
  221                                                                            
  222    *  Enabling the conveyance of Encrypted ClientHello keys [ECH]          
  223       associated with an alternative endpoint.                             
  224                                                                            
  225 1.2.  Overview of the SVCB RR                                              
  226                                                                            
  227    This subsection briefly describes the SVCB RR with forward references   
  228    to the full exposition of each component.  (As discussed in             
  229    Section 6, this all applies equally to the HTTPS RR, which shares the   
  230    same encoding, format, and high-level semantics.)                       
  231                                                                            
  232    The SVCB RR has two modes: 1) AliasMode (Section 2.4.2), which          
  233    aliases a name to another name and 2) ServiceMode (Section 2.4.3),      
  234    which provides connection information bound to a service endpoint       
  235    domain.  Placing both forms in a single RR type allows clients to       
  236    fetch the relevant information with a single query (Section 2.3).       
  237                                                                            
  238    The SVCB RR has two required fields and one optional field.  The        
  239    fields are:                                                             
  240                                                                            
  241    SvcPriority (Section 2.4.1):  The priority of this record (relative     
  242       to others, with lower values preferred).  A value of 0 indicates     
  243       AliasMode.                                                           
  244                                                                            
  245    TargetName:  The domain name of either the alias target (for            
  246       AliasMode) or the alternative endpoint (for ServiceMode).            
  247                                                                            
  248    SvcParams (optional):  A list of key=value pairs describing the         
  249       alternative endpoint at TargetName (only used in ServiceMode and     
  250       otherwise ignored).  SvcParams are described in Section 2.1.         
  251                                                                            
  252    Cooperating DNS recursive resolvers will perform subsequent record      
  253    resolution (for SVCB, A, and AAAA records) and return them in the       
  254    Additional section of the response (Section 4.2).  Clients either use   
  255    responses included in the Additional section returned by the            
  256    recursive resolver or perform necessary SVCB, A, and AAAA record        
  257    resolutions (Section 3).  DNS authoritative servers can attach in-      
  258    bailiwick SVCB, A, AAAA, and CNAME records in the Additional section    
  259    to responses for a SVCB query (Section 4.1).                            
  260                                                                            
  261    In ServiceMode, the SvcParams of the SVCB RR provide an extensible      
  262    data model for describing alternative endpoints that are                
  263    authoritative for a service, along with parameters associated with      
  264    each of these alternative endpoints (Section 7).                        
  265                                                                            
  266    For HTTP use cases, the HTTPS RR (Section 9) enables many of the        
  267    benefits of Alt-Svc [AltSvc] without waiting for a full HTTP            
  268    connection initiation (multiple round trips) before learning of the     
  269    preferred alternative, and without necessarily revealing the user's     
  270    intended destination to all entities along the network path.            
  271                                                                            
  272 1.3.  Terminology                                                          
  273                                                                            
  274    Terminology in this document is based on the common case where the      
  275    SVCB record is used to access a resource identified by a URI whose      
  276    authority field contains a DNS hostname as the host.                    
  277                                                                            
  278    *  The "service" is the information source identified by the            
  279       authority and scheme of the URI, capable of providing access to      
  280       the resource.  For "https" URIs, the "service" corresponds to an     
  281       "origin" [RFC6454].                                                  
  282                                                                            
  283    *  The "service name" is the host portion of the authority.             
  284                                                                            
  285    *  The "authority endpoint" is the authority's hostname and a port      
  286       number implied by the scheme or specified in the URI.                
  287                                                                            
  288    *  An "alternative endpoint" is a hostname, port number, and other      
  289       associated instructions to the client on how to reach an instance    
  290       of a service.                                                        
  291                                                                            
  292    Additional DNS terminology intends to be consistent with [DNSTerm].     
  293                                                                            
  294    SVCB is a contraction of "service binding".  The SVCB RR, HTTPS RR,     
  295    and future RR types that share SVCB's formats and registry are          
  296    collectively known as SVCB-compatible RR types.  The contraction        
  297    "SVCB" is also used to refer to this system as a whole.                 
  298                                                                            
  299    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  300    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and    
  301    "OPTIONAL" in this document are to be interpreted as described in       
  302    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all      
  303    capitals, as shown here.                                                
  304                                                                            
  305 2.  The SVCB Record Type                                                   
  306                                                                            
  307    The SVCB DNS RR type (RR type 64) is used to locate alternative         
  308    endpoints for a service.                                                
  309                                                                            
  310    The algorithm for resolving SVCB records and associated address         
  311    records is specified in Section 3.                                      
  312                                                                            
  313    Other SVCB-compatible RR types can also be defined as needed (see       
  314    Section 6).  In particular, the HTTPS RR (RR type 65) provides          
  315    special handling for the case of "https" origins as described in        
  316    Section 9.                                                              
  317                                                                            
  318    SVCB RRs are extensible by a list of SvcParams, which are pairs         
  319    consisting of a SvcParamKey and a SvcParamValue.  Each SvcParamKey      
  320    has a presentation name and a registered number.  Values are in a       
  321    format specific to the SvcParamKey.  Each SvcParam has a specified      
  322    presentation format (used in zone files) and wire encoding (e.g.,       
  323    domain names, binary data, or numeric values).  The initial             
  324    SvcParamKeys and their formats are defined in Section 7.                
  325                                                                            
  326 2.1.  Zone-File Presentation Format                                        
  327                                                                            
  328    The presentation format <RDATA> of the record ([RFC1035],               
  329    Section 5.1) has the form:                                              
  330                                                                            
  331    SvcPriority TargetName SvcParams                                        
  332                                                                            
  333    The SVCB record is defined specifically within the Internet ("IN")      
  334    Class ([RFC1035], Section 3.2.4).                                       
  335                                                                            
  336    SvcPriority is a number in the range 0-65535, TargetName is a           
  337    <domain-name> ([RFC1035], Section 5.1), and the SvcParams are a         
  338    whitespace-separated list with each SvcParam consisting of a            
  339    SvcParamKey=SvcParamValue pair or a standalone SvcParamKey.             
  340    SvcParamKeys are registered by IANA (Section 14.3).                     
  341                                                                            
  342    Each SvcParamKey SHALL appear at most once in the SvcParams.  In        
  343    presentation format, SvcParamKeys are lowercase alphanumeric strings.   
  344    Key names contain 1-63 characters from the ranges "a"-"z", "0"-"9",     
  345    and "-".  In ABNF [RFC5234],                                            
  346                                                                            
  347    alpha-lc      = %x61-7A   ; a-z                                         
  348    SvcParamKey   = 1*63(alpha-lc / DIGIT / "-")                            
  349    SvcParam      = SvcParamKey ["=" SvcParamValue]                         
  350    SvcParamValue = char-string ; See Appendix A.                           
  351    value         = *OCTET ; Value before key-specific parsing              
  352                                                                            
  353    The SvcParamValue is parsed using the character-string decoding         
  354    algorithm (Appendix A), producing a value.  The value is then           
  355    validated and converted into wire format in a manner specific to each   
  356    key.                                                                    
  357                                                                            
  358    When the optional "=" and SvcParamValue are omitted, the value is       
  359    interpreted as empty.                                                   
  360                                                                            
  361    Arbitrary keys can be represented using the unknown-key presentation    
  362    format "keyNNNNN" where NNNNN is the numeric value of the key type      
  363    without leading zeros.  A SvcParam in this form SHALL be parsed as      
  364    specified above, and the decoded value SHALL be used as its wire-       
  365    format encoding.                                                        
  366                                                                            
  367    For some SvcParamKeys, the value corresponds to a list or set of        
  368    items.  Presentation formats for such keys SHOULD use a comma-          
  369    separated list (Appendix A.1).                                          
  370                                                                            
  371    SvcParams in presentation format MAY appear in any order, but keys      
  372    MUST NOT be repeated.                                                   
  373                                                                            
  374 2.2.  RDATA Wire Format                                                    
  375                                                                            
  376    The RDATA for the SVCB RR consists of:                                  
  377                                                                            
  378    *  a 2-octet field for SvcPriority as an integer in network byte        
  379       order.                                                               
  380                                                                            
  381    *  the uncompressed, fully qualified TargetName, represented as a       
  382       sequence of length-prefixed labels per Section 3.1 of [RFC1035].     
  383                                                                            
  384    *  the SvcParams, consuming the remainder of the record (so smaller     
  385       than 65535 octets and constrained by the RDATA and DNS message       
  386       sizes).                                                              
  387                                                                            
  388    When the list of SvcParams is non-empty, it contains a series of        
  389    SvcParamKey=SvcParamValue pairs, represented as:                        
  390                                                                            
  391    *  a 2-octet field containing the SvcParamKey as an integer in          
  392       network byte order.  (See Section 14.3.2 for the defined values.)    
  393                                                                            
  394    *  a 2-octet field containing the length of the SvcParamValue as an     
  395       integer between 0 and 65535 in network byte order.                   
  396                                                                            
  397    *  an octet string of this length whose contents are the                
  398       SvcParamValue in a format determined by the SvcParamKey.             
  399                                                                            
  400    SvcParamKeys SHALL appear in increasing numeric order.                  
  401                                                                            
  402    Clients MUST consider an RR malformed if:                               
  403                                                                            
  404    *  the end of the RDATA occurs within a SvcParam.                       
  405                                                                            
  406    *  SvcParamKeys are not in strictly increasing numeric order.           
  407                                                                            
  408    *  the SvcParamValue for a SvcParamKey does not have the expected       
  409       format.                                                              
  410                                                                            
  411    Note that the second condition implies that there are no duplicate      
  412    SvcParamKeys.                                                           
  413                                                                            
  414    If any RRs are malformed, the client MUST reject the entire RRset and   
  415    fall back to non-SVCB connection establishment.                         
  416                                                                            
  417 2.3.  SVCB Query Names                                                     
  418                                                                            
  419    When querying the SVCB RR, a service is translated into a QNAME by      
  420    prepending the service name with a label indicating the scheme,         
  421    prefixed with an underscore, resulting in a domain name like            
  422    "_examplescheme.api.example.com.".  This follows the Attrleaf naming    
  423    pattern [Attrleaf], so the scheme MUST be registered appropriately      
  424    with IANA (see Section 11).                                             
  425                                                                            
  426    Protocol mapping documents MAY specify additional underscore-prefixed   
  427    labels to be prepended.  For schemes that specify a port                
  428    (Section 3.2.3 of [URI]), one reasonable possibility is to prepend      
  429    the indicated port number if a non-default port number is specified.    
  430    This document terms this behavior "Port Prefix Naming" and uses it in   
  431    the examples throughout.                                                
  432                                                                            
  433    See Section 9.1 for information regarding HTTPS RR behavior.            
  434                                                                            
  435    When a prior CNAME or SVCB record has aliased to a SVCB record, each    
  436    RR SHALL be returned under its own owner name, as in ordinary CNAME     
  437    processing ([RFC1034], Section 3.6.2).  For details, see the            
  438    recommendations regarding aliases for clients (Section 3), servers      
  439    (Section 4), and zones (Section 10).                                    
  440                                                                            
  441    Note that none of these forms alter the origin or authority for         
  442    validation purposes.  For example, TLS clients MUST continue to         
  443    validate TLS certificates for the original service name.                
  444                                                                            
  445    As an example, the owner of "example.com" could publish this record:    
  446                                                                            
  447    _8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net.            
  448                                                                            
  449    This record would indicate that "foo://api.example.com:8443" is         
  450    aliased to "svc4.example.net".  The owner of "example.net", in turn,    
  451    could publish this record:                                              
  452                                                                            
  453    svc4.example.net.  7200  IN SVCB 3 svc4.example.net. (                  
  454        alpn="bar" port="8004" )                                            
  455                                                                            
  456    This record would indicate that these services are served on port       
  457    number 8004, which supports the protocol "bar" and its associated       
  458    transport in addition to the default transport protocol for "foo://".   
  459                                                                            
  460    (Parentheses are used to ignore a line break in DNS zone-file           
  461    presentation format, per Section 5.1 of [RFC1035].)                     
  462                                                                            
  463 2.4.  Interpretation                                                       
  464                                                                            
  465 2.4.1.  SvcPriority                                                        
  466                                                                            
  467    When SvcPriority is 0, the SVCB record is in AliasMode                  
  468    (Section 2.4.2).  Otherwise, it is in ServiceMode (Section 2.4.3).      
  469                                                                            
  470    Within a SVCB RRset, all RRs SHOULD have the same mode.  If an RRset    
  471    contains a record in AliasMode, the recipient MUST ignore any           
  472    ServiceMode records in the set.                                         
  473                                                                            
  474    RRsets are explicitly unordered collections, so the SvcPriority field   
  475    is used to impose an ordering on SVCB RRs.  A smaller SvcPriority       
  476    indicates that the domain owner recommends the use of this record       
  477    over ServiceMode RRs with a larger SvcPriority value.                   
  478                                                                            
  479    When receiving an RRset containing multiple SVCB records with the       
  480    same SvcPriority value, clients SHOULD apply a random shuffle within    
  481    a priority level to the records before using them, to ensure uniform    
  482    load balancing.                                                         
  483                                                                            
  484 2.4.2.  AliasMode                                                          
  485                                                                            
  486    In AliasMode, the SVCB record aliases a service to a TargetName.        
  487    SVCB RRsets SHOULD only have a single RR in AliasMode.  If multiple     
  488    AliasMode RRs are present, clients or recursive resolvers SHOULD pick   
  489    one at random.                                                          
  490                                                                            
  491    The primary purpose of AliasMode is to allow aliasing at the zone       
  492    apex, where CNAME is not allowed (see, for example, [RFC1912],          
  493    Section 2.4).  In AliasMode, the TargetName will be the name of a       
  494    domain that resolves to SVCB, AAAA, and/or A records.  (See Section 6   
  495    for aliasing of SVCB-compatible RR types.)  Unlike CNAME, AliasMode     
  496    records do not affect the resolution of other RR types and apply only   
  497    to a specific service, not an entire domain name.                       
  498                                                                            
  499    The AliasMode TargetName SHOULD NOT be equal to the owner name, as      
  500    this would result in a loop.  In AliasMode, recipients MUST ignore      
  501    any SvcParams that are present.  Zone-file parsers MAY emit a warning   
  502    if an AliasMode record has SvcParams.  The use of SvcParams in          
  503    AliasMode records is currently not defined, but a future                
  504    specification could extend AliasMode records to include SvcParams.      
  505                                                                            
  506    For example, the operator of "foo://example.com:8080" could point       
  507    requests to a service operating at "foosvc.example.net" by              
  508    publishing:                                                             
  509                                                                            
  510    _8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net.              
  511                                                                            
  512    Using AliasMode maintains a separation of concerns: the owner of        
  513    "foosvc.example.net" can add or remove ServiceMode SVCB records         
  514    without requiring a corresponding change to "example.com".  Note that   
  515    if "foosvc.example.net" promises to always publish a SVCB record,       
  516    this AliasMode record can be replaced by a CNAME at the same owner      
  517    name.                                                                   
  518                                                                            
  519    AliasMode is especially useful for SVCB-compatible RR types that do     
  520    not require an underscore prefix, such as the HTTPS RR type.  For       
  521    example, the operator of "https://example.com" could point requests     
  522    to a server at "svc.example.net" by publishing this record at the       
  523    zone apex:                                                              
  524                                                                            
  525    example.com. 3600 IN HTTPS 0 svc.example.net.                           
  526                                                                            
  527    Note that the SVCB record's owner name MAY be the canonical name of a   
  528    CNAME record, and the TargetName MAY be the owner of a CNAME record.    
  529    Clients and recursive resolvers MUST follow CNAMEs as normal.           
  530                                                                            
  531    To avoid unbounded alias chains, clients and recursive resolvers MUST   
  532    impose a limit on the total number of SVCB aliases they will follow     
  533    for each resolution request.  This limit MUST NOT be zero, i.e.,        
  534    implementations MUST be able to follow at least one AliasMode record.   
  535    The exact value of this limit is left to implementations.               
  536                                                                            
  537    Zones that require following multiple AliasMode records could           
  538    encounter compatibility and performance issues.                         
  539                                                                            
  540    As legacy clients will not know to use this record, service operators   
  541    will likely need to retain fallback AAAA and A records alongside this   
  542    SVCB record, although in a common case the target of the SVCB record    
  543    might offer better performance, and therefore would be preferable for   
  544    clients implementing this specification to use.                         
  545                                                                            
  546    AliasMode records only apply to queries for the specific RR type.       
  547    For example, a SVCB record cannot alias to an HTTPS record or vice      
  548    versa.                                                                  
  549                                                                            
  550 2.4.3.  ServiceMode                                                        
  551                                                                            
  552    In ServiceMode, the TargetName and SvcParams within each RR associate   
  553    an alternative endpoint for the service with its connection             
  554    parameters.                                                             
  555                                                                            
  556    Each protocol scheme that uses SVCB MUST define a protocol mapping      
  557    that explains how SvcParams are applied for connections of that         
  558    scheme.  Unless specified otherwise by the protocol mapping, clients    
  559    MUST ignore any SvcParam that they do not recognize.                    
  560                                                                            
  561    Some SvcParams impose requirements on other SvcParams in the RR.  A     
  562    ServiceMode RR is called "self-consistent" if its SvcParams all         
  563    comply with each other's requirements.  Clients MUST reject any RR      
  564    whose recognized SvcParams are not self-consistent and MAY reject the   
  565    entire RRset.  To help zone operators avoid this condition, zone-file   
  566    implementations SHOULD enforce self-consistency as well.                
  567                                                                            
  568 2.5.  Special Handling of "." in TargetName                                
  569                                                                            
  570    If TargetName has the value "." (represented in the wire format as a    
  571    zero-length label), special rules apply.                                
  572                                                                            
  573 2.5.1.  AliasMode                                                          
  574                                                                            
  575    For AliasMode SVCB RRs, a TargetName of "." indicates that the          
  576    service is not available or does not exist.  This indication is         
  577    advisory: clients encountering this indication MAY ignore it and        
  578    attempt to connect without the use of SVCB.                             
  579                                                                            
  580 2.5.2.  ServiceMode                                                        
  581                                                                            
  582    For ServiceMode SVCB RRs, if TargetName has the value ".", then the     
  583    owner name of this record MUST be used as the effective TargetName.     
  584    If the record has a wildcard owner name in the zone file, the           
  585    recipient SHALL use the response's synthesized owner name as the        
  586    effective TargetName.                                                   
  587                                                                            
  588    Here, for example, "svc2.example.net" is the effective TargetName:      
  589                                                                            
  590    example.com.      7200  IN HTTPS 0 svc.example.net.                     
  591    svc.example.net.  7200  IN CNAME svc2.example.net.                      
  592    svc2.example.net. 7200  IN HTTPS 1 . port=8002                          
  593    svc2.example.net. 300   IN A     192.0.2.2                              
  594    svc2.example.net. 300   IN AAAA  2001:db8::2                            
  595                                                                            
  596 3.  Client Behavior                                                        
  597                                                                            
  598    "SVCB resolution" is the process of enumerating and ordering the        
  599    available endpoints for a service, as performed by the client.  SVCB    
  600    resolution is implemented as follows:                                   
  601                                                                            
  602    1.  Let $QNAME be the service name plus appropriate prefixes for the    
  603        scheme (see Section 2.3).                                           
  604                                                                            
  605    2.  Issue a SVCB query for $QNAME.                                      
  606                                                                            
  607    3.  If an AliasMode SVCB record is returned for $QNAME (after           
  608        following CNAMEs as normal), set $QNAME to its TargetName           
  609        (without additional prefixes) and loop back to Step 2, subject to   
  610        chain length limits and loop detection heuristics (see              
  611        Section 3.1).                                                       
  612                                                                            
  613    4.  If one or more "compatible" (Section 8) ServiceMode records are     
  614        returned, these represent the alternative endpoints.  Sort the      
  615        records by ascending SvcPriority.                                   
  616                                                                            
  617    5.  Otherwise, SVCB resolution has failed, and the list of available    
  618        endpoints is empty.                                                 
  619                                                                            
  620    This procedure does not rely on any recursive or authoritative DNS      
  621    server to comply with this specification or have any awareness of       
  622    SVCB.                                                                   
  623                                                                            
  624    A client is called "SVCB-optional" if it can connect without the use    
  625    of ServiceMode records; otherwise, it is called "SVCB-reliant".         
  626    Clients for pre-existing protocols (e.g., HTTP) SHALL implement SVCB-   
  627    optional behavior (except as noted in Section 3.1 or when modified by   
  628    future specifications).                                                 
  629                                                                            
  630    SVCB-optional clients SHOULD issue in parallel any other DNS queries    
  631    that might be needed for connection establishment if the SVCB record    
  632    is absent, in order to minimize delay in that case and enable the       
  633    optimizations discussed in Section 5.                                   
  634                                                                            
  635    Once SVCB resolution has concluded, whether successful or not, if at    
  636    least one AliasMode record was processed, SVCB-optional clients SHALL   
  637    append to the list of endpoints an endpoint consisting of the final     
  638    value of $QNAME, the authority endpoint's port number, and no           
  639    SvcParams.  (This endpoint will be attempted before falling back to     
  640    non-SVCB connection modes.  This ensures that SVCB-optional clients     
  641    will make use of an AliasMode record whose TargetName has A and/or      
  642    AAAA records but no SVCB records.)                                      
  643                                                                            
  644    The client proceeds with connection establishment using this list of    
  645    endpoints.  Clients SHOULD try higher-priority alternatives first,      
  646    with fallback to lower-priority alternatives.  Clients resolve AAAA     
  647    and/or A records for the selected TargetName and MAY choose between     
  648    them using an approach such as Happy Eyeballs [HappyEyeballsV2].        
  649                                                                            
  650    If the client is SVCB-optional and connecting using this list of        
  651    endpoints has failed, the client now attempts to use non-SVCB           
  652    connection modes.                                                       
  653                                                                            
  654    Some important optimizations are discussed in Section 5 to avoid        
  655    additional latency in comparison to ordinary AAAA/A lookups.            
  656                                                                            
  657 3.1.  Handling Resolution Failures                                         
  658                                                                            
  659    If DNS responses are cryptographically protected (e.g., using DNSSEC    
  660    or TLS [DoT] [DoH]) and SVCB resolution fails due to an                 
  661    authentication error, SERVFAIL response, transport error, or timeout,   
  662    the client SHOULD abandon its attempt to reach the service, even if     
  663    the client is SVCB-optional.  Otherwise, an active attacker could       
  664    mount a downgrade attack by denying the user access to the SvcParams.   
  665                                                                            
  666    A SERVFAIL error can occur if the domain is DNSSEC-signed, the          
  667    recursive resolver is DNSSEC-validating, and the attacker is between    
  668    the recursive resolver and the authoritative DNS server.  A transport   
  669    error or timeout can occur if an active attacker between the client     
  670    and the recursive resolver is selectively dropping SVCB queries or      
  671    responses, based on their size or other observable patterns.            
  672                                                                            
  673    If the client enforces DNSSEC validation on A/AAAA responses, it        
  674    SHOULD apply the same validation policy to SVCB.  Otherwise, an         
  675    attacker could defeat the A/AAAA protection by forging SVCB responses   
  676    that direct the client to other IP addresses.                           
  677                                                                            
  678    If DNS responses are not cryptographically protected, clients MAY       
  679    treat SVCB resolution failure as fatal or nonfatal.                     
  680                                                                            
  681    If the client is unable to complete SVCB resolution due to its chain    
  682    length limit, the client MUST fall back to the authority endpoint, as   
  683    if the service's SVCB record did not exist.                             
  684                                                                            
  685 3.2.  Clients Using a Proxy                                                
  686                                                                            
  687    Clients using a domain-oriented transport proxy like HTTP CONNECT       
  688    ([RFC7231], Section 4.3.6) or SOCKS5 [RFC1928] have the option of       
  689    using named destinations, in which case the client does not perform     
  690    any A or AAAA queries for destination domains.  If the client is        
  691    configured to use named destinations with a proxy that does not         
  692    provide SVCB query capability (e.g., through an affiliated DNS          
  693    resolver), the client would have to perform SVCB resolution             
  694    separately, likely disclosing the destinations to additional parties    
  695    and not just the proxy.  Clients in this configuration SHOULD arrange   
  696    for a separate SVCB resolution procedure with appropriate privacy       
  697    properties.  If this is not possible, SVCB-optional clients MUST        
  698    disable SVCB resolution entirely, and SVCB-reliant clients MUST treat   
  699    the configuration as invalid.                                           
  700                                                                            
  701    If the client does use SVCB and named destinations, the client SHOULD   
  702    follow the standard SVCB resolution process, selecting the smallest-    
  703    SvcPriority option that is compatible with the client and the proxy.    
  704    When connecting using a SVCB record, clients MUST provide the final     
  705    TargetName and port to the proxy, which will perform any required A     
  706    and AAAA lookups.                                                       
  707                                                                            
  708    This arrangement has several benefits:                                  
  709                                                                            
  710    *  Compared to disabling SVCB:                                          
  711                                                                            
  712       -  It allows the client to use the SvcParams, if present, which      
  713          are only usable with a specific TargetName.  The SvcParams may    
  714          include information that enhances performance (e.g., supported    
  715          protocols) and privacy.                                           
  716                                                                            
  717       -  It allows a service on an apex domain to use aliasing.            
  718                                                                            
  719    *  Compared to providing the proxy with an IP address:                  
  720                                                                            
  721       -  It allows the proxy to select between IPv4 and IPv6 addresses     
  722          for the server according to its configuration.                    
  723                                                                            
  724       -  It ensures that the proxy receives addresses based on its         
  725          network geolocation, not the client's.                            
  726                                                                            
  727       -  It enables faster fallback for TCP destinations with multiple     
  728          addresses of the same family.                                     
  729                                                                            
  730 4.  DNS Server Behavior                                                    
  731                                                                            
  732 4.1.  Authoritative Servers                                                
  733                                                                            
  734    When replying to a SVCB query, authoritative DNS servers SHOULD         
  735    return A, AAAA, and SVCB records in the Additional section for any      
  736    TargetNames that are in the zone.  If the zone is signed, the server    
  737    SHOULD also include DNSSEC records authenticating the existence or      
  738    nonexistence of these records in the Additional section.                
  739                                                                            
  740    See Section 4.4 for exceptions.                                         
  741                                                                            
  742 4.2.  Recursive Resolvers                                                  
  743                                                                            
  744    Whether the recursive resolver is aware of SVCB or not, the normal      
  745    response construction process used for unknown RR types [RFC3597]       
  746    generates the Answer section of the response.  Recursive resolvers      
  747    that are aware of SVCB SHOULD help the client to execute the            
  748    procedure in Section 3 with minimum overall latency by incorporating    
  749    additional useful information into the Additional section of the        
  750    response as follows:                                                    
  751                                                                            
  752    1.  Incorporate the results of SVCB resolution.  If the recursive       
  753        resolver's local chain length limit (which may be different from    
  754        the client's limit) has been reached, terminate.                    
  755                                                                            
  756    2.  If any of the resolved SVCB records are in AliasMode, choose one    
  757        of them at random, and resolve SVCB, A, and AAAA records for its    
  758        TargetName.                                                         
  759                                                                            
  760        *  If any SVCB records are resolved, go to Step 1.                  
  761                                                                            
  762        *  Otherwise, incorporate the results of A and AAAA resolution,     
  763           and terminate.                                                   
  764                                                                            
  765    3.  All the resolved SVCB records are in ServiceMode.  Resolve A and    
  766        AAAA queries for each TargetName (or for the owner name if          
  767        TargetName is "."), incorporate all the results, and terminate.     
  768                                                                            
  769    In this procedure, "resolve" means the resolver's ordinary recursive    
  770    resolution procedure, as if processing a query for that RRset.  This    
  771    includes following any aliases that the resolver would ordinarily       
  772    follow (e.g., CNAME, DNAME [DNAME]).  Errors or anomalies in            
  773    obtaining additional records MAY cause this process to terminate but    
  774    MUST NOT themselves cause the resolver to send a failure response.      
  775                                                                            
  776    See Section 2.4.2 for additional safeguards for recursive resolvers     
  777    to implement to mitigate loops.                                         
  778                                                                            
  779    See Section 5.2 for possible optimizations of this procedure.           
  780                                                                            
  781 4.2.1.  DNS64                                                              
  782                                                                            
  783    DNS64 resolvers synthesize responses to AAAA queries for names that     
  784    only have an A record (Section 5.1.7 of [RFC6147]).  SVCB-aware DNS64   
  785    resolvers SHOULD apply the same synthesis logic when resolving AAAA     
  786    records for the TargetName for inclusion in the Additional section      
  787    (Step 2 in Section 4.2) and MAY omit the A records from this section.   
  788                                                                            
  789    DNS64 resolvers MUST NOT extrapolate the AAAA synthesis logic to the    
  790    IP hints in the SvcParams (Section 7.3).  Modifying the IP hints        
  791    would break DNSSEC validation for the SVCB record and would not         
  792    improve performance when the above recommendation is implemented.       
  793                                                                            
  794 4.3.  General Requirements                                                 
  795                                                                            
  796    Recursive resolvers MUST be able to convey SVCB records with            
  797    unrecognized SvcParamKeys.  Resolvers MAY accomplish this by treating   
  798    the entire SvcParams portion of the record as opaque, even if the       
  799    contents are invalid.  If a recognized SvcParamKey is followed by a     
  800    value that is invalid according to the SvcParam's specification, a      
  801    recursive resolver MAY report an error such as SERVFAIL instead of      
  802    returning the record.  For complex value types whose interpretation     
  803    might differ between implementations or have additional future          
  804    allowed values added (e.g., URIs or "alpn"), resolvers SHOULD limit     
  805    validation to specified constraints.                                    
  806                                                                            
  807    When responding to a query that includes the DNSSEC OK bit [RFC3225],   
  808    DNSSEC-capable recursive and authoritative DNS servers MUST accompany   
  809    each RRset in the Additional section with the same DNSSEC-related       
  810    records that they would send when providing that RRset as an Answer     
  811    (e.g., RRSIG, NSEC, NSEC3).                                             
  812                                                                            
  813    According to Section 5.4.1 of [RFC2181], "Unauthenticated RRs           
  814    received and cached from ... the additional data section ... should     
  815    not be cached in such a way that they would ever be returned as         
  816    answers to a received query.  They may be returned as additional        
  817    information where appropriate."  Recursive resolvers therefore MAY      
  818    cache records from the Additional section for use in populating         
  819    Additional section responses and MAY cache them for general use if      
  820    they are authenticated by DNSSEC.                                       
  821                                                                            
  822 4.4.  EDNS Client Subnet (ECS)                                             
  823                                                                            
  824    The EDNS Client Subnet (ECS) option [RFC7871] allows recursive          
  825    resolvers to request IP addresses that are suitable for a particular    
  826    client IP range.  SVCB records may contain IP addresses (in ipv*hint    
  827    SvcParams) or direct users to a subnet-specific TargetName, so          
  828    recursive resolvers SHOULD include the same ECS option in SVCB          
  829    queries as in A/AAAA queries.                                           
  830                                                                            
  831    According to Section 7.3.1 of [RFC7871], "Any records from [the         
  832    Additional section] MUST NOT be tied to a network."  Accordingly,       
  833    when processing a response whose QTYPE is SVCB-compatible, resolvers    
  834    SHOULD treat any records in the Additional section as having SOURCE     
  835    PREFIX-LENGTH set to zero and SCOPE PREFIX-LENGTH as specified in the   
  836    ECS option.  Authoritative servers MUST omit such records if they are   
  837    not suitable for use by any stub resolvers that set SOURCE PREFIX-      
  838    LENGTH to zero.  This will cause the resolver to perform a follow-up    
  839    query that can receive a properly tailored ECS.  (This is similar to    
  840    the usage of CNAME with the ECS option as discussed in [RFC7871],       
  841    Section 7.2.1.)                                                         
  842                                                                            
  843    Authoritative servers that omit Additional records can avoid the        
  844    added latency of a follow-up query by following the advice in           
  845    Section 10.2.                                                           
  846                                                                            
  847 5.  Performance Optimizations                                              
  848                                                                            
  849    For optimal performance (i.e., minimum connection setup time),          
  850    clients SHOULD implement a client-side DNS cache.  Responses in the     
  851    Additional section of a SVCB response SHOULD be placed in cache         
  852    before performing any follow-up queries.  With this behavior, and       
  853    with conforming DNS servers, using SVCB does not add network latency    
  854    to connection setup.                                                    
  855                                                                            
  856    To improve performance when using a non-conforming recursive            
  857    resolver, clients SHOULD issue speculative A and/or AAAA queries in     
  858    parallel with each SVCB query, based on a predicted value of            
  859    TargetName (see Section 10.2).                                          
  860                                                                            
  861    After a ServiceMode RRset is received, clients MAY try more than one    
  862    option in parallel and MAY prefetch A and AAAA records for multiple     
  863    TargetNames.                                                            
  864                                                                            
  865 5.1.  Optimistic Pre-connection and Connection Reuse                       
  866                                                                            
  867    If an address response arrives before the corresponding SVCB            
  868    response, the client MAY initiate a connection as if the SVCB query     
  869    returned NODATA but MUST NOT transmit any information that could be     
  870    altered by the SVCB response until it arrives.  For example, future     
  871    SvcParamKeys could be defined that alter the TLS ClientHello.           
  872                                                                            
  873    Clients implementing this optimization SHOULD wait for 50               
  874    milliseconds before starting optimistic pre-connection, as per the      
  875    guidance in [HappyEyeballsV2].                                          
  876                                                                            
  877    A SVCB record is consistent with a connection if the client would       
  878    attempt an equivalent connection when making use of that record.  If    
  879    a SVCB record is consistent with an active or in-progress connection    
  880    C, the client MAY prefer that record and use C as its connection.       
  881    For example, suppose the client receives this SVCB RRset for a          
  882    protocol that uses TLS over TCP:                                        
  883                                                                            
  884    _1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. (               
  885        ipv6hint=2001:db8::1 port=1234 )                                    
  886                                   SVCB 2 svc2.example.net. (               
  887        ipv6hint=2001:db8::2 port=1234 )                                    
  888                                                                            
  889    If the client has an in-progress TCP connection to                      
  890    [2001:db8::2]:1234, it MAY proceed with TLS on that connection, even    
  891    though the other record in the RRset has higher priority.               
  892                                                                            
  893    If none of the SVCB records are consistent with any active or in-       
  894    progress connection, clients proceed with connection establishment as   
  895    described in Section 3.                                                 
  896                                                                            
  897 5.2.  Generating and Using Incomplete Responses                            
  898                                                                            
  899    When following the procedure in Section 4.2, recursive resolvers MAY    
  900    terminate the procedure early and produce a reply that omits some of    
  901    the associated RRsets.  This is REQUIRED when the chain length limit    
  902    is reached (Step 1 in Section 4.2) but might also be appropriate when   
  903    the maximum response size is reached or when responding before fully    
  904    chasing dependencies would improve performance.  When omitting          
  905    certain RRsets, recursive resolvers SHOULD prioritize information for   
  906    smaller-SvcPriority records.                                            
  907                                                                            
  908    As discussed in Section 3, clients MUST be able to fetch additional     
  909    information that is required to use a SVCB record, if it is not         
  910    included in the initial response.  As a performance optimization, if    
  911    some of the SVCB records in the response can be used without            
  912    requiring additional DNS queries, the client MAY prefer those           
  913    records, regardless of their priorities.                                
  914                                                                            
  915 6.  SVCB-Compatible RR Types                                               
  916                                                                            
  917    An RR type is called "SVCB-compatible" if it permits an                 
  918    implementation that is identical to SVCB in its:                        
  919                                                                            
  920    *  RDATA presentation format                                            
  921                                                                            
  922    *  RDATA wire format                                                    
  923                                                                            
  924    *  IANA registry used for SvcParamKeys                                  
  925                                                                            
  926    *  Authoritative server Additional section processing                   
  927                                                                            
  928    *  Recursive resolution process                                         
  929                                                                            
  930    *  Relevant Class (i.e., Internet ("IN") [RFC1035])                     
  931                                                                            
  932    This allows authoritative and recursive DNS servers to apply            
  933    identical processing to all SVCB-compatible RR types.                   
  934                                                                            
  935    All other behaviors described as applying to the SVCB RR also apply     
  936    to all SVCB-compatible RR types unless explicitly stated otherwise.     
  937    When following an AliasMode record (Section 2.4.2) of RR type $T, the   
  938    follow-up query to the TargetName MUST also be for type $T.             
  939                                                                            
  940    This document defines one SVCB-compatible RR type (other than SVCB      
  941    itself): the HTTPS RR type (Section 9), which avoids Attrleaf label     
  942    prefixes [Attrleaf] in order to improve compatibility with wildcards    
  943    and CNAMEs, which are widely used with HTTP.                            
  944                                                                            
  945    Standards authors should consider carefully whether to use SVCB or      
  946    define a new SVCB-compatible RR type, as this choice cannot easily be   
  947    reversed after deployment.                                              
  948                                                                            
  949 7.  Initial SvcParamKeys                                                   
  950                                                                            
  951    A few initial SvcParamKeys are defined here.  These keys are useful     
  952    for the "https" scheme, and most are expected to be generally           
  953    applicable to other schemes as well.                                    
  954                                                                            
  955    Each new protocol mapping document MUST specify which keys are          
  956    applicable and safe to use.  Protocol mappings MAY alter the            
  957    interpretation of SvcParamKeys but MUST NOT alter their presentation    
  958    or wire formats.                                                        
  959                                                                            
  960 7.1.  "alpn" and "no-default-alpn"                                         
  961                                                                            
  962    The "alpn" and "no-default-alpn" SvcParamKeys together indicate the     
  963    set of Application-Layer Protocol Negotiation (ALPN) protocol           
  964    identifiers [ALPN] and associated transport protocols supported by      
  965    this service endpoint (the "SVCB ALPN set").                            
  966                                                                            
  967    As with Alt-Svc [AltSvc], each ALPN protocol identifier is used to      
  968    identify the application protocol and associated suite of protocols     
  969    supported by the endpoint (the "protocol suite").  The presence of an   
  970    ALPN protocol identifier in the SVCB ALPN set indicates that this       
  971    service endpoint, described by TargetName and the other parameters      
  972    (e.g., "port"), offers service with the protocol suite associated       
  973    with this ALPN identifier.                                              
  974                                                                            
  975    Clients filter the set of ALPN identifiers to match the protocol        
  976    suites they support, and this informs the underlying transport          
  977    protocol used (such as QUIC over UDP or TLS over TCP).  ALPN protocol   
  978    identifiers that do not uniquely identify a protocol suite (e.g., an    
  979    Identification Sequence that can be used with both TLS and DTLS) are    
  980    not compatible with this SvcParamKey and MUST NOT be included in the    
  981    SVCB ALPN set.                                                          
  982                                                                            
  983 7.1.1.  Representation                                                     
  984                                                                            
  985    ALPNs are identified by their registered "Identification Sequence"      
  986    (alpn-id), which is a sequence of 1-255 octets.                         
  987                                                                            
  988    alpn-id = 1*255OCTET                                                    
  989                                                                            
  990    For "alpn", the presentation value SHALL be a comma-separated list      
  991    (Appendix A.1) of one or more alpn-ids.  Zone-file implementations      
  992    MAY disallow the "," and "\" characters in ALPN IDs instead of          
  993    implementing the value-list escaping procedure, relying on the opaque   
  994    key format (e.g., key1=\002h2) in the event that these characters are   
  995    needed.                                                                 
  996                                                                            
  997    The wire-format value for "alpn" consists of at least one alpn-id       
  998    prefixed by its length as a single octet, and these length-value        
  999    pairs are concatenated to form the SvcParamValue.  These pairs MUST     
 1000    exactly fill the SvcParamValue; otherwise, the SvcParamValue is         
 1001    malformed.                                                              
 1002                                                                            
 1003    For "no-default-alpn", the presentation and wire-format values MUST     
 1004    be empty.  When "no-default-alpn" is specified in an RR, "alpn" must    
 1005    also be specified in order for the RR to be "self-consistent"           
 1006    (Section 2.4.3).                                                        
 1007                                                                            
 1008    Each scheme that uses this SvcParamKey defines a "default set" of       
 1009    ALPN IDs that are supported by nearly all clients and servers; this     
 1010    set MAY be empty.  To determine the SVCB ALPN set, the client starts    
 1011    with the list of alpn-ids from the "alpn" SvcParamKey, and it adds      
 1012    the default set unless the "no-default-alpn" SvcParamKey is present.    
 1013                                                                            
 1014 7.1.2.  Use                                                                
 1015                                                                            
 1016    To establish a connection to the endpoint, clients MUST                 
 1017                                                                            
 1018    1.  Let SVCB-ALPN-Intersection be the set of protocols in the SVCB      
 1019        ALPN set that the client supports.                                  
 1020                                                                            
 1021    2.  Let Intersection-Transports be the set of transports (e.g., TLS,    
 1022        DTLS, QUIC) implied by the protocols in SVCB-ALPN-Intersection.     
 1023                                                                            
 1024    3.  For each transport in Intersection-Transports, construct a          
 1025        ProtocolNameList containing the Identification Sequences of all     
 1026        the client's supported ALPN protocols for that transport, without   
 1027        regard to the SVCB ALPN set.                                        
 1028                                                                            
 1029    For example, if the SVCB ALPN set is ["http/1.1", "h3"] and the         
 1030    client supports HTTP/1.1, HTTP/2, and HTTP/3, the client could          
 1031    attempt to connect using TLS over TCP with a ProtocolNameList of        
 1032    ["http/1.1", "h2"] and could also attempt a connection using QUIC       
 1033    with a ProtocolNameList of ["h3"].                                      
 1034                                                                            
 1035    Once the client has constructed a ClientHello, protocol negotiation     
 1036    in that handshake proceeds as specified in [ALPN], without regard to    
 1037    the SVCB ALPN set.                                                      
 1038                                                                            
 1039    Clients MAY implement a fallback procedure, using a less-preferred      
 1040    transport if more-preferred transports fail to connect.  This           
 1041    fallback behavior is vulnerable to manipulation by a network attacker   
 1042    who blocks the more-preferred transports, but it may be necessary for   
 1043    compatibility with existing networks.                                   
 1044                                                                            
 1045    With this procedure in place, an attacker who can modify DNS and        
 1046    network traffic can prevent a successful transport connection but       
 1047    cannot otherwise interfere with ALPN protocol selection.  This          
 1048    procedure also ensures that each ProtocolNameList includes at least     
 1049    one protocol from the SVCB ALPN set.                                    
 1050                                                                            
 1051    Clients SHOULD NOT attempt connection to a service endpoint whose       
 1052    SVCB ALPN set does not contain any supported protocols.                 
 1053                                                                            
 1054    To ensure consistency of behavior, clients MAY reject the entire SVCB   
 1055    RRset and fall back to basic connection establishment if all of the     
 1056    compatible RRs indicate "no-default-alpn", even if connection could     
 1057    have succeeded using a non-default ALPN protocol.                       
 1058                                                                            
 1059    Zone operators SHOULD ensure that at least one RR in each RRset         
 1060    supports the default transports.  This enables compatibility with the   
 1061    greatest number of clients.                                             
 1062                                                                            
 1063 7.2.  "port"                                                               
 1064                                                                            
 1065    The "port" SvcParamKey defines the TCP or UDP port that should be       
 1066    used to reach this alternative endpoint.  If this key is not present,   
 1067    clients SHALL use the authority endpoint's port number.                 
 1068                                                                            
 1069    The presentation value of the SvcParamValue is a single decimal         
 1070    integer between 0 and 65535 in ASCII.  Any other value (e.g., an        
 1071    empty value) is a syntax error.  To enable simpler parsing, this        
 1072    SvcParamValue MUST NOT contain escape sequences.                        
 1073                                                                            
 1074    The wire format of the SvcParamValue is the corresponding 2-octet       
 1075    numeric value in network byte order.                                    
 1076                                                                            
 1077    If a port-restricting firewall is in place between some client and      
 1078    the service endpoint, changing the port number might cause that         
 1079    client to lose access to the service, so operators should exercise      
 1080    caution when using this SvcParamKey to specify a non-default port.      
 1081                                                                            
 1082 7.3.  "ipv4hint" and "ipv6hint"                                            
 1083                                                                            
 1084    The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients     
 1085    MAY use to reach the service.  If A and AAAA records for TargetName     
 1086    are locally available, the client SHOULD ignore these hints.            
 1087    Otherwise, clients SHOULD perform A and/or AAAA queries for             
 1088    TargetName per Section 3, and clients SHOULD use the IP address in      
 1089    those responses for future connections.  Clients MAY opt to terminate   
 1090    any connections using the addresses in hints and instead switch to      
 1091    the addresses in response to the TargetName query.  Failure to use A    
 1092    and/or AAAA response addresses could negatively impact load balancing   
 1093    or other geo-aware features and thereby degrade client performance.     
 1094                                                                            
 1095    The presentation value SHALL be a comma-separated list (Appendix A.1)   
 1096    of one or more IP addresses of the appropriate family in standard       
 1097    textual format [RFC5952] [RFC4001].  To enable simpler parsing, this    
 1098    SvcParamValue MUST NOT contain escape sequences.                        
 1099                                                                            
 1100    The wire format for each parameter is a sequence of IP addresses in     
 1101    network byte order (for the respective address family).  Like an A or   
 1102    AAAA RRset, the list of addresses represents an unordered collection,   
 1103    and clients SHOULD pick addresses to use in a random order.  An empty   
 1104    list of addresses is invalid.                                           
 1105                                                                            
 1106    When selecting between IPv4 and IPv6 addresses to use, clients may      
 1107    use an approach such as Happy Eyeballs [HappyEyeballsV2].  When only    
 1108    "ipv4hint" is present, NAT64 clients may synthesize IPv6 addresses as   
 1109    specified in [RFC7050] or ignore the "ipv4hint" key and wait for AAAA   
 1110    resolution (Section 3).  For best performance, server operators         
 1111    SHOULD include an "ipv6hint" parameter whenever they include an         
 1112    "ipv4hint" parameter.                                                   
 1113                                                                            
 1114    These parameters are intended to minimize additional connection         
 1115    latency when a recursive resolver is not compliant with the             
 1116    requirements in Section 4 and SHOULD NOT be included if most clients    
 1117    are using compliant recursive resolvers.  When TargetName is the        
 1118    service name or the owner name (which can be written as "."), server    
 1119    operators SHOULD NOT include these hints, because they are unlikely     
 1120    to convey any performance benefit.                                      
 1121                                                                            
 1122 7.4.  "mandatory"                                                          
 1123                                                                            
 1124    See Section 8.                                                          
 1125                                                                            
 1126 8.  ServiceMode RR Compatibility and Mandatory Keys                        
 1127                                                                            
 1128    In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the     
 1129    RR will not function correctly for clients that ignore this             
 1130    SvcParamKey.  Each SVCB protocol mapping SHOULD specify a set of keys   
 1131    that are "automatically mandatory", i.e., mandatory if they are         
 1132    present in an RR.  The SvcParamKey "mandatory" is used to indicate      
 1133    any mandatory keys for this RR, in addition to any automatically        
 1134    mandatory keys that are present.                                        
 1135                                                                            
 1136    A ServiceMode RR is considered "compatible" by a client if the client   
 1137    recognizes all the mandatory keys and their values indicate that        
 1138    successful connection establishment is possible.  Incompatible RRs      
 1139    are ignored (see step 5 of the procedure defined in Section 3).         
 1140                                                                            
 1141    The presentation value SHALL be a comma-separated list (Appendix A.1)   
 1142    of one or more valid SvcParamKeys, either by their registered name or   
 1143    in the unknown-key format (Section 2.1).  Keys MAY appear in any        
 1144    order but MUST NOT appear more than once.  For self-consistency         
 1145    (Section 2.4.3), listed keys MUST also appear in the SvcParams.         
 1146                                                                            
 1147    To enable simpler parsing, this SvcParamValue MUST NOT contain escape   
 1148    sequences.                                                              
 1149                                                                            
 1150    For example, the following is a valid list of SvcParams:                
 1151                                                                            
 1152    ipv6hint=... key65333=ex1 key65444=ex2 mandatory=key65444,ipv6hint      
 1153                                                                            
 1154    In wire format, the keys are represented by their numeric values in     
 1155    network byte order, concatenated in strictly increasing numeric         
 1156    order.                                                                  
 1157                                                                            
 1158    This SvcParamKey is always automatically mandatory and MUST NOT         
 1159    appear in its own value-list.  Other automatically mandatory keys       
 1160    SHOULD NOT appear in the list either.  (Including them wastes space     
 1161    and otherwise has no effect.)                                           
 1162                                                                            
 1163 9.  Using Service Bindings with HTTP                                       
 1164                                                                            
 1165    The use of any protocol with SVCB requires a protocol-specific          
 1166    mapping specification.  This section specifies the mapping for the      
 1167    "http" and "https" URI schemes [HTTP].                                  
 1168                                                                            
 1169    To enable special handling for HTTP use cases, the HTTPS RR type is     
 1170    defined as a SVCB-compatible RR type, specific to the "https" and       
 1171    "http" schemes.  Clients MUST NOT perform SVCB queries or accept SVCB   
 1172    responses for "https" or "http" schemes.                                
 1173                                                                            
 1174    The presentation format of the record is:                               
 1175                                                                            
 1176    Name TTL IN HTTPS SvcPriority TargetName SvcParams                      
 1177                                                                            
 1178    All the SvcParamKeys defined in Section 7 are permitted for use in      
 1179    HTTPS RRs.  The default set of ALPN IDs is the single value             
 1180    "http/1.1".  The "automatically mandatory" keys (Section 8) are         
 1181    "port" and "no-default-alpn".  (As described in Section 8, clients      
 1182    must either implement these keys or ignore any RR in which they         
 1183    appear.)  Clients that restrict the destination port in "https" URIs    
 1184    (e.g., using the "bad ports" list from [FETCH]) SHOULD apply the same   
 1185    restriction to the "port" SvcParam.                                     
 1186                                                                            
 1187    The presence of an HTTPS RR for an origin also indicates that clients   
 1188    should connect securely and use the "https" scheme, as discussed in     
 1189    Section 9.5.  This allows HTTPS RRs to apply to pre-existing "http"     
 1190    scheme URLs, while ensuring that the client uses a secure and           
 1191    authenticated connection.                                               
 1192                                                                            
 1193    The HTTPS RR parallels the concepts introduced in "HTTP Alternative     
 1194    Services" [AltSvc].  Clients and servers that implement HTTPS RRs are   
 1195    not required to implement Alt-Svc.                                      
 1196                                                                            
 1197 9.1.  Query Names for HTTPS RRs                                            
 1198                                                                            
 1199    The HTTPS RR uses Port Prefix Naming (Section 2.3), with one            
 1200    modification: if the scheme is "https" and the port is 443, then the    
 1201    client's original QNAME is equal to the service name (i.e., the         
 1202    origin's hostname), without any prefix labels.                          
 1203                                                                            
 1204    By removing the Attrleaf labels [Attrleaf] used in SVCB, this           
 1205    construction enables offline DNSSEC signing of wildcard domains,        
 1206    which are commonly used with HTTP.  Using the service name as the       
 1207    owner name of the HTTPS record, without prefixes, also allows the       
 1208    targets of existing CNAME chains (e.g., CDN hosts) to start returning   
 1209    HTTPS RR responses without requiring origin domains to configure and    
 1210    maintain an additional delegation.                                      
 1211                                                                            
 1212    The procedure for following HTTPS AliasMode RRs and CNAME aliases is    
 1213    unchanged from SVCB (as described in Sections 2.4.2 and 3).             
 1214                                                                            
 1215    Clients always convert "http" URLs to "https" before performing an      
 1216    HTTPS RR query using the process described in Section 9.5, so domain    
 1217    owners MUST NOT publish HTTPS RRs with a prefix of "_http".             
 1218                                                                            
 1219    Note that none of these forms alter the HTTPS origin or authority.      
 1220    For example, clients MUST continue to validate TLS certificate          
 1221    hostnames based on the origin.                                          
 1222                                                                            
 1223 9.2.  Comparison with Alt-Svc                                              
 1224                                                                            
 1225    Publishing a ServiceMode HTTPS RR in DNS is intended to be similar to   
 1226    transmitting an Alt-Svc field value over HTTP, and receiving an HTTPS   
 1227    RR is intended to be similar to receiving that field value over HTTP.   
 1228    However, there are some differences in the intended client and server   
 1229    behavior.                                                               
 1230                                                                            
 1231 9.2.1.  ALPN Usage                                                         
 1232                                                                            
 1233    Unlike Alt-Svc field values, HTTPS RRs can contain multiple ALPN IDs.   
 1234    The meaning and use of these IDs are discussed in Section 7.1.2.        
 1235                                                                            
 1236 9.2.2.  Untrusted Channels                                                 
 1237                                                                            
 1238    HTTPS records do not require or provide any assurance of                
 1239    authenticity.  (DNSSEC signing and verification, which would provide    
 1240    such assurance, are OPTIONAL.)  The DNS resolution process is modeled   
 1241    as an untrusted channel that might be controlled by an attacker, so     
 1242    Alt-Svc parameters that cannot be safely received in this model MUST    
 1243    NOT have a corresponding defined SvcParamKey.  For example, there is    
 1244    no SvcParamKey corresponding to the Alt-Svc "persist" parameter,        
 1245    because this parameter is not safe to accept over an untrusted          
 1246    channel.                                                                
 1247                                                                            
 1248 9.2.3.  Cache Lifetime                                                     
 1249                                                                            
 1250    There is no SvcParamKey corresponding to the Alt-Svc "ma" (max age)     
 1251    parameter.  Instead, server operators encode the expiration time in     
 1252    the DNS TTL.                                                            
 1253                                                                            
 1254    The appropriate TTL value might be different from the "ma" value used   
 1255    for Alt-Svc, depending on the desired efficiency and agility.  Some     
 1256    DNS caches incorrectly extend the lifetime of DNS records beyond the    
 1257    stated TTL, so server operators cannot rely on HTTPS RRs expiring on    
 1258    time.  Shortening the TTL to compensate for incorrect caching is NOT    
 1259    RECOMMENDED, as this practice impairs the performance of correctly      
 1260    functioning caches and does not guarantee faster expiration from        
 1261    incorrect caches.  Instead, server operators SHOULD maintain            
 1262    compatibility with expired records until they observe that nearly all   
 1263    connections have migrated to the new configuration.                     
 1264                                                                            
 1265 9.2.4.  Granularity                                                        
 1266                                                                            
 1267    Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc       
 1268    field value specifically to the client.  When using an HTTPS RR,        
 1269    groups of clients will necessarily receive the same SvcParams.          
 1270    Therefore, HTTPS RRs are not suitable for uses that require single-     
 1271    client granularity.                                                     
 1272                                                                            
 1273 9.3.  Interaction with Alt-Svc                                             
 1274                                                                            
 1275    Clients that implement support for both Alt-Svc and HTTPS records and   
 1276    are making a connection based on a cached Alt-Svc response SHOULD       
 1277    retrieve any HTTPS records for the Alt-Svc alt-authority and ensure     
 1278    that their connection attempts are consistent with both the Alt-Svc     
 1279    parameters and any received HTTPS SvcParams.  If present, the HTTPS     
 1280    record's TargetName and port are used for connection establishment      
 1281    (per Section 3).  For example, suppose that "https://example.com"       
 1282    sends an Alt-Svc field value of:                                        
 1283                                                                            
 1284    Alt-Svc: h2="alt.example:443", h2="alt2.example:443", h3=":8443"        
 1285                                                                            
 1286    The client would retrieve the following HTTPS records:                  
 1287                                                                            
 1288    alt.example.              IN HTTPS 1 . alpn=h2,h3 foo=...               
 1289    alt2.example.             IN HTTPS 1 alt2b.example. alpn=h3 foo=...     
 1290    _8443._https.example.com. IN HTTPS 1 alt3.example. (                    
 1291        port=9443 alpn=h2,h3 foo=... )                                      
 1292                                                                            
 1293    Based on these inputs, the following connection attempts would always   
 1294    be allowed:                                                             
 1295                                                                            
 1296    *  HTTP/2 to alt.example:443                                            
 1297                                                                            
 1298    *  HTTP/3 to alt3.example:9443                                          
 1299                                                                            
 1300    *  Fallback to the client's non-Alt-Svc connection behavior             
 1301                                                                            
 1302    The following connection attempts would not be allowed:                 
 1303                                                                            
 1304    *  HTTP/3 to alt.example:443 (not consistent with Alt-Svc)              
 1305                                                                            
 1306    *  Any connection to alt2b.example (no ALPN ID consistent with both     
 1307       the HTTPS record and Alt-Svc)                                        
 1308                                                                            
 1309    *  HTTPS over TCP to any port on alt3.example (not consistent with      
 1310       Alt-Svc)                                                             
 1311                                                                            
 1312    Suppose that "foo" is a SvcParamKey that renders the client SVCB-       
 1313    reliant.  The following Alt-Svc-only connection attempts would be       
 1314    allowed only if the client does not support "foo", as they rely on      
 1315    SVCB-optional fallback behavior:                                        
 1316                                                                            
 1317    *  HTTP/2 to alt2.example:443                                           
 1318                                                                            
 1319    *  HTTP/3 to example.com:8443                                           
 1320                                                                            
 1321    Alt-authorities SHOULD carry the same SvcParams as the origin unless    
 1322    a deviation is specifically known to be safe.  As noted in              
 1323    Section 2.4 of [AltSvc], clients MAY disallow any Alt-Svc connection    
 1324    according to their own criteria, e.g., disallowing Alt-Svc              
 1325    connections that lack support for privacy features that are available   
 1326    on the authority endpoint.                                              
 1327                                                                            
 1328 9.4.  Requiring Server Name Indication                                     
 1329                                                                            
 1330    Clients MUST NOT use an HTTPS RR response unless the client supports    
 1331    the TLS Server Name Indication (SNI) extension and indicates the        
 1332    origin name in the TLS ClientHello (which might be encrypted via a      
 1333    future specification such as [ECH]).  This supports the conservation    
 1334    of IP addresses.                                                        
 1335                                                                            
 1336    Note that the TLS SNI (and also the HTTP "Host" or ":authority") will   
 1337    indicate the origin, not the TargetName.                                
 1338                                                                            
 1339 9.5.  HTTP Strict Transport Security (HSTS)                                
 1340                                                                            
 1341    An HTTPS RR directs the client to communicate with this host only       
 1342    over a secure transport, similar to HSTS [HSTS].  Prior to making an    
 1343    "http" scheme request, the client SHOULD perform a lookup to            
 1344    determine if any HTTPS RRs exist for that origin.  To do so, the        
 1345    client SHOULD construct a corresponding "https" URL as follows:         
 1346                                                                            
 1347    1.  Replace the "http" scheme with "https".                             
 1348                                                                            
 1349    2.  If the "http" URL explicitly specifies port 80, specify port 443.   
 1350                                                                            
 1351    3.  Do not alter any other aspect of the URL.                           
 1352                                                                            
 1353    This construction is equivalent to Section 8.3 of [HSTS], Step 5.       
 1354                                                                            
 1355    If an HTTPS RR query for this "https" URL returns any AliasMode HTTPS   
 1356    RRs or any compatible ServiceMode HTTPS RRs (see Section 8), the        
 1357    client SHOULD behave as if it has received an HTTP 307 (Temporary       
 1358    Redirect) status code with this "https" URL in the "Location" field.    
 1359    (Receipt of an incompatible ServiceMode RR does not trigger the         
 1360    redirect behavior.)  Because HTTPS RRs are received over an often-      
 1361    insecure channel (DNS), clients MUST NOT place any more trust in this   
 1362    signal than if they had received a 307 (Temporary Redirect) response    
 1363    over cleartext HTTP.                                                    
 1364                                                                            
 1365    Publishing an HTTPS RR can potentially lead to unexpected results or    
 1366    a loss in functionality in cases where the "http" resource neither      
 1367    redirects to the "https" resource nor references the same underlying    
 1368    resource.                                                               
 1369                                                                            
 1370    When an "https" connection fails due to an error in the underlying      
 1371    secure transport, such as an error in certificate validation, some      
 1372    clients currently offer a "user recourse" that allows the user to       
 1373    bypass the security error and connect anyway.  When making an "https"   
 1374    scheme request to an origin with an HTTPS RR, either directly or via    
 1375    the above redirect, such a client MAY remove the user recourse          
 1376    option.  Origins that publish HTTPS RRs therefore MUST NOT rely on      
 1377    user recourse for access.  For more information, see Sections 8.4 and   
 1378    12.1 of [HSTS].                                                         
 1379                                                                            
 1380 9.6.  Use of HTTPS RRs in Other Protocols                                  
 1381                                                                            
 1382    All HTTP connections to named origins are eligible to use HTTPS RRs,    
 1383    even when HTTP is used as part of another protocol or without an        
 1384    explicit HTTP-related URI scheme (Section 4.2 of [HTTP]).  For          
 1385    example, clients that support HTTPS RRs and implement [WebSocket]       
 1386    using the altered opening handshake from [FETCH-WEBSOCKETS] SHOULD      
 1387    use HTTPS RRs for the requestURL.                                       
 1388                                                                            
 1389    When HTTP is used in a context where URLs or redirects are not          
 1390    applicable (e.g., connections to an HTTP proxy), clients that find a    
 1391    corresponding HTTPS RR SHOULD implement security upgrade behavior       
 1392    equivalent to that specified in Section 9.5.                            
 1393                                                                            
 1394    Such protocols MAY define their own SVCB mappings, which MAY be         
 1395    defined to take precedence over HTTPS RRs.                              
 1396                                                                            
 1397 10.  Zone Structures                                                       
 1398                                                                            
 1399 10.1.  Structuring Zones for Flexibility                                   
 1400                                                                            
 1401    Each ServiceMode RRset can only serve a single scheme.  The scheme is   
 1402    indicated by the owner name and the RR type.  For the generic SVCB RR   
 1403    type, this means that each owner name can only be used for a single     
 1404    scheme.  The underscore prefixing requirement (Section 2.3) ensures     
 1405    that this is true for the initial query, but it is the responsibility   
 1406    of zone owners to choose names that satisfy this constraint when        
 1407    using aliases, including CNAME and AliasMode records.                   
 1408                                                                            
 1409    When using the generic SVCB RR type with aliasing, zone owners SHOULD   
 1410    choose alias target names that indicate the scheme in use (e.g.,        
 1411    "foosvc.example.net" for "foo" schemes).  This will help to avoid       
 1412    confusion when another scheme needs to be added to the configuration.   
 1413    When multiple port numbers are in use, it may be helpful to repeat      
 1414    the prefix labels in the alias target name (e.g.,                       
 1415    "_1234._foo.svc.example.net").                                          
 1416                                                                            
 1417 10.2.  Structuring Zones for Performance                                   
 1418                                                                            
 1419    To avoid a delay for clients using a non-conforming recursive           
 1420    resolver, domain owners SHOULD minimize the use of AliasMode records    
 1421    and SHOULD choose TargetName according to a predictable convention      
 1422    that is known to the client, so that clients can issue A and/or AAAA    
 1423    queries for TargetName in advance (see Section 5).  Unless otherwise    
 1424    specified, the convention is to set TargetName to the service name      
 1425    for an initial ServiceMode record, or to "." if it is reached via an    
 1426    alias.                                                                  
 1427                                                                            
 1428    $ORIGIN example.com. ; Origin                                           
 1429    foo                  3600 IN CNAME foosvc.example.net.                  
 1430    _8080._foo.foo       3600 IN CNAME foosvc.example.net.                  
 1431    bar                   300 IN AAAA 2001:db8::2                           
 1432    _9090._bar.bar       3600 IN SVCB 1 bar key65444=...                    
 1433                                                                            
 1434    $ORIGIN example.net. ; Service provider zone                            
 1435    foosvc               3600 IN SVCB 1 . key65333=...                      
 1436    foosvc                300 IN AAAA 2001:db8::1                           
 1437                                                                            
 1438            Figure 1: "foo://foo.example.com:8080" Is Available at          
 1439       "foosvc.example.net", but "bar://bar.example.com:9090" Is Served     
 1440                                   Locally                                  
 1441                                                                            
 1442    Domain owners SHOULD avoid using a TargetName that is below a DNAME,    
 1443    as this is likely unnecessary and makes responses slower and larger.    
 1444    Also, zone structures that require following more than eight aliases    
 1445    (counting both AliasMode and CNAME records) are NOT RECOMMENDED.        
 1446                                                                            
 1447 10.3.  Operational Considerations                                          
 1448                                                                            
 1449    Some authoritative DNS servers may not allow A or AAAA records on       
 1450    names starting with an underscore (e.g., [BIND-CHECK-NAMES]).  This     
 1451    could create an operational issue when the TargetName contains an       
 1452    Attrleaf label, or when using a TargetName of "." if the owner name     
 1453    contains an Attrleaf label.                                             
 1454                                                                            
 1455 10.4.  Examples                                                            
 1456                                                                            
 1457 10.4.1.  Protocol Enhancements                                             
 1458                                                                            
 1459    Consider a simple zone of the form:                                     
 1460                                                                            
 1461    $ORIGIN simple.example. ; Simple example zone                           
 1462    @ 300 IN A    192.0.2.1                                                 
 1463             AAAA 2001:db8::1                                               
 1464                                                                            
 1465    The domain owner could add this record:                                 
 1466                                                                            
 1467    @ 7200 IN HTTPS 1 . alpn=h3                                             
 1468                                                                            
 1469    This record would indicate that "https://simple.example" supports       
 1470    QUIC in addition to HTTP/1.1 over TLS over TCP (the implicit            
 1471    default).  The record could also include other information (e.g., a     
 1472    non-standard port).  For "https://simple.example:8443", the record      
 1473    would be:                                                               
 1474                                                                            
 1475    _8443._https 7200 IN HTTPS 1 . alpn=h3                                  
 1476                                                                            
 1477    These records also respectively tell clients to replace the scheme      
 1478    with "https" when loading "http://simple.example" or                    
 1479    "http://simple.example:8443".                                           
 1480                                                                            
 1481 10.4.2.  Apex Aliasing                                                     
 1482                                                                            
 1483    Consider a zone that is using CNAME aliasing:                           
 1484                                                                            
 1485    $ORIGIN aliased.example. ; A zone that is using a hosting service       
 1486    ; Subdomain aliased to a high-performance server pool                   
 1487    www             7200 IN CNAME pool.svc.example.                         
 1488    ; Apex domain on fixed IPs because CNAME is not allowed at the apex     
 1489    @                300 IN A     192.0.2.1                                 
 1490                         IN AAAA  2001:db8::1                               
 1491                                                                            
 1492    With HTTPS RRs, the owner of aliased.example could alias the apex by    
 1493    adding one additional record:                                           
 1494                                                                            
 1495    @               7200 IN HTTPS 0 pool.svc.example.                       
 1496                                                                            
 1497    With this record in place, HTTPS-RR-aware clients will use the same     
 1498    server pool for aliased.example and www.aliased.example.  (They will    
 1499    also upgrade "http://aliased.example/..." to "https".)  Non-HTTPS-RR-   
 1500    aware clients will just ignore the new record.                          
 1501                                                                            
 1502    Similar to CNAME, HTTPS RRs have no impact on the origin name.  When    
 1503    connecting, clients will continue to treat the authoritative origins    
 1504    as "https://www.aliased.example" and "https://aliased.example",         
 1505    respectively, and will validate TLS server certificates accordingly.    
 1506                                                                            
 1507 10.4.3.  Parameter Binding                                                 
 1508                                                                            
 1509    Suppose that svc.example's primary server pool supports HTTP/3 but      
 1510    its backup server pool does not.  This can be expressed in the          
 1511    following form:                                                         
 1512                                                                            
 1513    $ORIGIN svc.example. ; A hosting provider                               
 1514    pool  7200 IN HTTPS 1 . alpn=h2,h3                                      
 1515                  HTTPS 2 backup alpn=h2 port=8443                          
 1516    pool   300 IN A        192.0.2.2                                        
 1517                  AAAA     2001:db8::2                                      
 1518    backup 300 IN A        192.0.2.3                                        
 1519                  AAAA     2001:db8::3                                      
 1520                                                                            
 1521    This configuration is entirely compatible with the "apex aliasing"      
 1522    example, whether the client supports HTTPS RRs or not.  If the client   
 1523    does support HTTPS RRs, all connections will be upgraded to HTTPS,      
 1524    and clients will use HTTP/3 if they can.  Parameters are "bound" to     
 1525    each server pool, so each server pool can have its own protocol, port   
 1526    number, etc.                                                            
 1527                                                                            
 1528 10.4.4.  Multi-CDN Configuration                                           
 1529                                                                            
 1530    The HTTPS RR is intended to support HTTPS services operated by          
 1531    multiple independent entities, such as different CDNs or different      
 1532    hosting providers.  This includes the case where a service is           
 1533    migrated from one operator to another, as well as the case where the    
 1534    service is multiplexed between multiple operators for performance,      
 1535    redundancy, etc.                                                        
 1536                                                                            
 1537    This example shows such a configuration, with www.customer.example      
 1538    having different DNS responses to different queries, either over time   
 1539    or due to logic within the authoritative DNS server:                    
 1540                                                                            
 1541     ; This zone contains/returns different CNAME records                   
 1542     ; at different points in time.  The RRset for "www" can                
 1543     ; only ever contain a single CNAME.                                    
 1544                                                                            
 1545     ; Sometimes the zone has:                                              
 1546     $ORIGIN customer.example.  ; A multi-CDN customer domain               
 1547     www 900 IN CNAME cdn1.svc1.example.                                    
 1548                                                                            
 1549     ; and other times it contains:                                         
 1550     $ORIGIN customer.example.                                              
 1551     www 900 IN CNAME customer.svc2.example.                                
 1552                                                                            
 1553     ; and yet other times it contains:                                     
 1554     $ORIGIN customer.example.                                              
 1555     www 900 IN CNAME cdn3.svc3.example.                                    
 1556                                                                            
 1557     ; With the following remaining constant and always included:           
 1558     $ORIGIN customer.example.  ; A multi-CDN customer domain               
 1559     ; The apex is also aliased to www to match its configuration.          
 1560     @     7200 IN HTTPS 0 www                                              
 1561     ; Non-HTTPS-aware clients use non-CDN IPs.                             
 1562                   A    203.0.113.82                                        
 1563                   AAAA 2001:db8:203::2                                     
 1564                                                                            
 1565     ; Resolutions following the cdn1.svc1.example                          
 1566     ; path use these records.                                              
 1567     ; This CDN uses a different alternative service for HTTP/3.            
 1568     $ORIGIN svc1.example.  ; domain for CDN 1                              
 1569     cdn1     1800 IN HTTPS 1 h3pool alpn=h3                                
 1570                      HTTPS 2 . alpn=h2                                     
 1571                      A    192.0.2.2                                        
 1572                      AAAA 2001:db8:192::4                                  
 1573     h3pool 300 IN A 192.0.2.3                                              
 1574                AAAA 2001:db8:192:7::3                                      
 1575                                                                            
 1576     ; Resolutions following the customer.svc2.example                      
 1577     ; path use these records.                                              
 1578     ; Note that this CDN only supports HTTP/2.                             
 1579     $ORIGIN svc2.example. ; domain operated by CDN 2                       
 1580     customer 300 IN HTTPS 1 . alpn=h2                                      
 1581               60 IN A    198.51.100.2                                      
 1582                     A    198.51.100.3                                      
 1583                     A    198.51.100.4                                      
 1584                     AAAA 2001:db8:198::7                                   
 1585                     AAAA 2001:db8:198::12                                  
 1586                                                                            
 1587     ; Resolutions following the cdn3.svc3.example                          
 1588     ; path use these records.                                              
 1589     ; Note that this CDN has no HTTPS records.                             
 1590     $ORIGIN svc3.example. ; domain operated by CDN 3                       
 1591     cdn3      60 IN A    203.0.113.8                                       
 1592                     AAAA 2001:db8:113::8                                   
 1593                                                                            
 1594    Note that in the above example, the different CDNs have different       
 1595    configurations and different capabilities, but clients will use HTTPS   
 1596    RRs as a bound-together unit.                                           
 1597                                                                            
 1598    Domain owners should be cautious when using a multi-CDN                 
 1599    configuration, as it introduces a number of complexities highlighted    
 1600    by this example:                                                        
 1601                                                                            
 1602    *  If CDN 1 supports a desired protocol or feature and CDN 2 does       
 1603       not, the client is vulnerable to downgrade by a network adversary    
 1604       who forces clients to get CDN 2 records.                             
 1605                                                                            
 1606    *  Aliasing the apex to its subdomain simplifies the zone file but      
 1607       likely increases resolution latency, especially when using a non-    
 1608       HTTPS-aware recursive resolver.  An alternative would be to alias    
 1609       the zone apex directly to a name managed by a CDN.                   
 1610                                                                            
 1611    *  The A, AAAA, and HTTPS resolutions are independent lookups, so       
 1612       resolvers may observe and follow different CNAMEs to different       
 1613       CDNs.  Clients may thus find that the A and AAAA responses do not    
 1614       correspond to the TargetName in the HTTPS response; these clients    
 1615       will need to perform additional queries to retrieve the correct IP   
 1616       addresses.  Including ipv6hint and ipv4hint will reduce the          
 1617       performance impact of this case.                                     
 1618                                                                            
 1619    *  If not all CDNs publish HTTPS records, clients will sometimes        
 1620       receive NODATA for HTTPS queries (as with cdn3.svc3.example above)   
 1621       but could receive A/AAAA records from a different CDN.  Clients      
 1622       will attempt to connect to this CDN without the benefit of its       
 1623       HTTPS records.                                                       
 1624                                                                            
 1625 10.4.5.  Non-HTTP Uses                                                     
 1626                                                                            
 1627    For protocols other than HTTP, the SVCB RR and an Attrleaf label        
 1628    [Attrleaf] will be used.  For example, to reach an example resource     
 1629    of "baz://api.example.com:8765", the following SVCB record would be     
 1630    used to alias it to "svc4-baz.example.net.", which in turn could        
 1631    return AAAA/A records and/or SVCB records in ServiceMode:               
 1632                                                                            
 1633    _8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net.        
 1634                                                                            
 1635    HTTPS RRs use similar Attrleaf labels if the origin contains a non-     
 1636    default port.                                                           
 1637                                                                            
 1638 11.  Interaction with Other Standards                                      
 1639                                                                            
 1640    This standard is intended to reduce connection latency and improve      
 1641    user privacy.  Server operators implementing this standard SHOULD       
 1642    also implement TLS 1.3 [RFC8446] and Online Certificate Status          
 1643    Protocol (OCSP) Stapling (i.e., Certificate Status Request in           
 1644    Section 8 of [RFC6066]), both of which confer substantial performance   
 1645    and privacy benefits when used in combination with SVCB records.        
 1646                                                                            
 1647    To realize the greatest privacy benefits, this proposal is intended     
 1648    for use over a privacy-preserving DNS transport (like DNS over TLS      
 1649    [DoT] or DNS over HTTPS [DoH]).  However, performance improvements,     
 1650    and some modest privacy improvements, are possible without the use of   
 1651    those standards.                                                        
 1652                                                                            
 1653    Any specification for the use of SVCB with a protocol MUST have an      
 1654    entry for its scheme under the SVCB RR type in the IANA DNS             
 1655    "Underscored and Globally Scoped DNS Node Names" registry [Attrleaf].   
 1656    The scheme MUST have an entry in the "Uniform Resource Identifier       
 1657    (URI) Schemes" registry [RFC7595] and MUST have a defined               
 1658    specification for use with SVCB.                                        
 1659                                                                            
 1660 12.  Security Considerations                                               
 1661                                                                            
 1662    SVCB/HTTPS RRs permit distribution over untrusted channels, and         
 1663    clients are REQUIRED to verify that the alternative endpoint is         
 1664    authoritative for the service (similar to Section 2.1 of [AltSvc]).     
 1665    Therefore, DNSSEC signing and validation are OPTIONAL for publishing    
 1666    and using SVCB and HTTPS RRs.                                           
 1667                                                                            
 1668    Clients MUST ensure that their DNS cache is partitioned for each        
 1669    local network, or flushed on network changes, to prevent a local        
 1670    adversary in one network from implanting a forged DNS record that       
 1671    allows them to track users or hinder their connections after they       
 1672    leave that network.                                                     
 1673                                                                            
 1674    An attacker who can prevent SVCB resolution can deny clients any        
 1675    associated security benefits.  A hostile recursive resolver can         
 1676    always deny service to SVCB queries, but network intermediaries can     
 1677    often prevent resolution as well, even when the client and recursive    
 1678    resolver validate DNSSEC and use a secure transport.  These downgrade   
 1679    attacks can prevent the "https" upgrade provided by the HTTPS RR        
 1680    (Section 9.5) and can disable any other protections coordinated via     
 1681    SvcParams.  To prevent downgrades, Section 3.1 recommends that          
 1682    clients abandon the connection attempt when such an attack is           
 1683    detected.                                                               
 1684                                                                            
 1685    A hostile DNS intermediary might forge AliasMode "." records            
 1686    (Section 2.5.1) as a way to block clients from accessing particular     
 1687    services.  Such an adversary could already block entire domains by      
 1688    forging erroneous responses, but this mechanism allows them to target   
 1689    particular protocols or ports within a domain.  Clients that might be   
 1690    subject to such attacks SHOULD ignore AliasMode "." records.            
 1691                                                                            
 1692    A hostile DNS intermediary or authoritative server can return SVCB      
 1693    records indicating any IP address and port number, including IP         
 1694    addresses inside the local network and port numbers assigned to         
 1695    internal services.  If the attacker can influence the client's          
 1696    payload (e.g., TLS session ticket contents) and an internal service     
 1697    has a sufficiently lax parser, the attacker could gain access to the    
 1698    internal service.  (The same concerns apply to SRV records, HTTP Alt-   
 1699    Svc, and HTTP redirects.)  As a mitigation, SVCB mapping documents      
 1700    SHOULD indicate any port number restrictions that are appropriate for   
 1701    the supported transports.                                               
 1702                                                                            
 1703 13.  Privacy Considerations                                                
 1704                                                                            
 1705    Standard address queries reveal the user's intent to access a           
 1706    particular domain.  This information is visible to the recursive        
 1707    resolver, and to many other parties when plaintext DNS transport is     
 1708    used.  SVCB queries, like queries for SRV records and other specific    
 1709    RR types, additionally reveal the user's intent to use a particular     
 1710    protocol.  This is not normally sensitive information, but it should    
 1711    be considered when adding SVCB support in a new context.                
 1712                                                                            
 1713 14.  IANA Considerations                                                   
 1714                                                                            
 1715 14.1.  SVCB RR Type                                                        
 1716                                                                            
 1717    IANA has registered the following new DNS RR type in the "Resource      
 1718    Record (RR) TYPEs" registry on the "Domain Name System (DNS)            
 1719    Parameters" page:                                                       
 1720                                                                            
 1721    Type:  SVCB                                                             
 1722    Value:  64                                                              
 1723    Meaning:  General-purpose service binding                               
 1724    Reference:  RFC 9460                                                    
 1725                                                                            
 1726 14.2.  HTTPS RR Type                                                       
 1727                                                                            
 1728    IANA has registered the following new DNS RR type in the "Resource      
 1729    Record (RR) TYPEs" registry on the "Domain Name System (DNS)            
 1730    Parameters" page:                                                       
 1731                                                                            
 1732    Type:  HTTPS                                                            
 1733    Value:  65                                                              
 1734    Meaning:  SVCB-compatible type for use with HTTP                        
 1735    Reference:  RFC 9460                                                    
 1736                                                                            
 1737 14.3.  New Registry for Service Parameters                                 
 1738                                                                            
 1739    IANA has created the "Service Parameter Keys (SvcParamKeys)" registry   
 1740    in the "Domain Name System (DNS) Parameters" category on a new page     
 1741    entitled "DNS Service Bindings (SVCB)".  This registry defines the      
 1742    namespace for parameters, including string representations and          
 1743    numeric SvcParamKey values.  This registry is shared with other SVCB-   
 1744    compatible RR types, such as the HTTPS RR.                              
 1745                                                                            
 1746 14.3.1.  Procedure                                                         
 1747                                                                            
 1748    A registration MUST include the following fields:                       
 1749                                                                            
 1750    Number:  Wire-format numeric identifier (range 0-65535)                 
 1751    Name:  Unique presentation name                                         
 1752    Meaning:  A short description                                           
 1753    Reference:  Location of specification or registration source            
 1754    Change Controller:  Person or entity, with contact information if       
 1755       appropriate                                                          
 1756                                                                            
 1757    The characters in the registered Name field entry MUST be lowercase     
 1758    alphanumeric or "-" (Section 2.1).  The name MUST NOT start with        
 1759    "key" or "invalid".                                                     
 1760                                                                            
 1761    The registration policy for new entries is Expert Review ([RFC8126],    
 1762    Section 4.5).  The designated expert MUST ensure that the reference     
 1763    is stable and publicly available and that it specifies how to convert   
 1764    the SvcParamValue's presentation format to wire format.  The            
 1765    reference MAY be any individual's Internet-Draft or a document from     
 1766    any other source with similar assurances of stability and               
 1767    availability.  An entry MAY specify a reference of the form "Same as    
 1768    (other key name)" if it uses the same presentation and wire formats     
 1769    as an existing key.                                                     
 1770                                                                            
 1771    This arrangement supports the development of new parameters while       
 1772    ensuring that zone files can be made interoperable.                     
 1773                                                                            
 1774 14.3.2.  Initial Contents                                                  
 1775                                                                            
 1776    The "Service Parameter Keys (SvcParamKeys)" registry has been           
 1777    populated with the following initial registrations:                     
 1778                                                                            
 1779    +===========+=================+================+=========+==========+   
 1780    |   Number  | Name            | Meaning        |Reference|Change    |   
 1781    |           |                 |                |         |Controller|   
 1782    +===========+=================+================+=========+==========+   
 1783    |     0     | mandatory       | Mandatory      |RFC 9460,|IETF      |   
 1784    |           |                 | keys in this   |Section 8|          |   
 1785    |           |                 | RR             |         |          |   
 1786    +-----------+-----------------+----------------+---------+----------+   
 1787    |     1     | alpn            | Additional     |RFC 9460,|IETF      |   
 1788    |           |                 | supported      |Section  |          |   
 1789    |           |                 | protocols      |7.1      |          |   
 1790    +-----------+-----------------+----------------+---------+----------+   
 1791    |     2     | no-default-alpn | No support     |RFC 9460,|IETF      |   
 1792    |           |                 | for default    |Section  |          |   
 1793    |           |                 | protocol       |7.1      |          |   
 1794    +-----------+-----------------+----------------+---------+----------+   
 1795    |     3     | port            | Port for       |RFC 9460,|IETF      |   
 1796    |           |                 | alternative    |Section  |          |   
 1797    |           |                 | endpoint       |7.2      |          |   
 1798    +-----------+-----------------+----------------+---------+----------+   
 1799    |     4     | ipv4hint        | IPv4 address   |RFC 9460,|IETF      |   
 1800    |           |                 | hints          |Section  |          |   
 1801    |           |                 |                |7.3      |          |   
 1802    +-----------+-----------------+----------------+---------+----------+   
 1803    |     5     | ech             | RESERVED       |N/A      |IETF      |   
 1804    |           |                 | (held for      |         |          |   
 1805    |           |                 | Encrypted      |         |          |   
 1806    |           |                 | ClientHello)   |         |          |   
 1807    +-----------+-----------------+----------------+---------+----------+   
 1808    |     6     | ipv6hint        | IPv6 address   |RFC 9460,|IETF      |   
 1809    |           |                 | hints          |Section  |          |   
 1810    |           |                 |                |7.3      |          |   
 1811    +-----------+-----------------+----------------+---------+----------+   
 1812    |65280-65534| N/A             | Reserved for   |RFC 9460 |IETF      |   
 1813    |           |                 | Private Use    |         |          |   
 1814    +-----------+-----------------+----------------+---------+----------+   
 1815    |   65535   | N/A             | Reserved       |RFC 9460 |IETF      |   
 1816    |           |                 | ("Invalid      |         |          |   
 1817    |           |                 | key")          |         |          |   
 1818    +-----------+-----------------+----------------+---------+----------+   
 1819                                                                            
 1820                                   Table 1                                  
 1821                                                                            
 1822 14.4.  Other Registry Updates                                              
 1823                                                                            
 1824    Per [Attrleaf], the following entry has been added to the DNS           
 1825    "Underscored and Globally Scoped DNS Node Names" registry:              
 1826                                                                            
 1827                    +=========+============+===========+                    
 1828                    | RR Type | _NODE NAME | Reference |                    
 1829                    +=========+============+===========+                    
 1830                    | HTTPS   | _https     | RFC 9460  |                    
 1831                    +---------+------------+-----------+                    
 1832                                                                            
 1833                                  Table 2                                   
 1834                                                                            
 1835 15.  References                                                            
 1836                                                                            
 1837 15.1.  Normative References                                                
 1838                                                                            
 1839    [ALPN]     Friedl, S., Popov, A., Langley, A., and E. Stephan,          
 1840               "Transport Layer Security (TLS) Application-Layer Protocol   
 1841               Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,      
 1842               July 2014, <https://www.rfc-editor.org/info/rfc7301>.        
 1843                                                                            
 1844    [Attrleaf] Crocker, D., "Scoped Interpretation of DNS Resource          
 1845               Records through "Underscored" Naming of Attribute Leaves",   
 1846               BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,         
 1847               <https://www.rfc-editor.org/info/rfc8552>.                   
 1848                                                                            
 1849    [DoH]      Hoffman, P. and P. McManus, "DNS Queries over HTTPS          
 1850               (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,        
 1851               <https://www.rfc-editor.org/info/rfc8484>.                   
 1852                                                                            
 1853    [DoT]      Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,     
 1854               and P. Hoffman, "Specification for DNS over Transport        
 1855               Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May   
 1856               2016, <https://www.rfc-editor.org/info/rfc7858>.             
 1857                                                                            
 1858    [HappyEyeballsV2]                                                       
 1859               Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:        
 1860               Better Connectivity Using Concurrency", RFC 8305,            
 1861               DOI 10.17487/RFC8305, December 2017,                         
 1862               <https://www.rfc-editor.org/info/rfc8305>.                   
 1863                                                                            
 1864    [HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,      
 1865               Ed., "HTTP Semantics", STD 97, RFC 9110,                     
 1866               DOI 10.17487/RFC9110, June 2022,                             
 1867               <https://www.rfc-editor.org/info/rfc9110>.                   
 1868                                                                            
 1869    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",   
 1870               STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,       
 1871               <https://www.rfc-editor.org/info/rfc1034>.                   
 1872                                                                            
 1873    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
 1874               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,      
 1875               November 1987, <https://www.rfc-editor.org/info/rfc1035>.    
 1876                                                                            
 1877    [RFC1928]  Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and    
 1878               L. Jones, "SOCKS Protocol Version 5", RFC 1928,              
 1879               DOI 10.17487/RFC1928, March 1996,                            
 1880               <https://www.rfc-editor.org/info/rfc1928>.                   
 1881                                                                            
 1882    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
 1883               Requirement Levels", BCP 14, RFC 2119,                       
 1884               DOI 10.17487/RFC2119, March 1997,                            
 1885               <https://www.rfc-editor.org/info/rfc2119>.                   
 1886                                                                            
 1887    [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS              
 1888               Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,   
 1889               <https://www.rfc-editor.org/info/rfc2181>.                   
 1890                                                                            
 1891    [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC",         
 1892               RFC 3225, DOI 10.17487/RFC3225, December 2001,               
 1893               <https://www.rfc-editor.org/info/rfc3225>.                   
 1894                                                                            
 1895    [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record     
 1896               (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September       
 1897               2003, <https://www.rfc-editor.org/info/rfc3597>.             
 1898                                                                            
 1899    [RFC4001]  Daniele, M., Haberman, B., Routhier, S., and J.              
 1900               Schoenwaelder, "Textual Conventions for Internet Network     
 1901               Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005,   
 1902               <https://www.rfc-editor.org/info/rfc4001>.                   
 1903                                                                            
 1904    [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax   
 1905               Specifications: ABNF", STD 68, RFC 5234,                     
 1906               DOI 10.17487/RFC5234, January 2008,                          
 1907               <https://www.rfc-editor.org/info/rfc5234>.                   
 1908                                                                            
 1909    [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6    
 1910               Address Text Representation", RFC 5952,                      
 1911               DOI 10.17487/RFC5952, August 2010,                           
 1912               <https://www.rfc-editor.org/info/rfc5952>.                   
 1913                                                                            
 1914    [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)            
 1915               Extensions: Extension Definitions", RFC 6066,                
 1916               DOI 10.17487/RFC6066, January 2011,                          
 1917               <https://www.rfc-editor.org/info/rfc6066>.                   
 1918                                                                            
 1919    [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van          
 1920               Beijnum, "DNS64: DNS Extensions for Network Address          
 1921               Translation from IPv6 Clients to IPv4 Servers", RFC 6147,    
 1922               DOI 10.17487/RFC6147, April 2011,                            
 1923               <https://www.rfc-editor.org/info/rfc6147>.                   
 1924                                                                            
 1925    [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of     
 1926               the IPv6 Prefix Used for IPv6 Address Synthesis",            
 1927               RFC 7050, DOI 10.17487/RFC7050, November 2013,               
 1928               <https://www.rfc-editor.org/info/rfc7050>.                   
 1929                                                                            
 1930    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer   
 1931               Protocol (HTTP/1.1): Semantics and Content", RFC 7231,       
 1932               DOI 10.17487/RFC7231, June 2014,                             
 1933               <https://www.rfc-editor.org/info/rfc7231>.                   
 1934                                                                            
 1935    [RFC7595]  Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines      
 1936               and Registration Procedures for URI Schemes", BCP 35,        
 1937               RFC 7595, DOI 10.17487/RFC7595, June 2015,                   
 1938               <https://www.rfc-editor.org/info/rfc7595>.                   
 1939                                                                            
 1940    [RFC7871]  Contavalli, C., van der Gaast, W., Lawrence, D., and W.      
 1941               Kumari, "Client Subnet in DNS Queries", RFC 7871,            
 1942               DOI 10.17487/RFC7871, May 2016,                              
 1943               <https://www.rfc-editor.org/info/rfc7871>.                   
 1944                                                                            
 1945    [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for        
 1946               Writing an IANA Considerations Section in RFCs", BCP 26,     
 1947               RFC 8126, DOI 10.17487/RFC8126, June 2017,                   
 1948               <https://www.rfc-editor.org/info/rfc8126>.                   
 1949                                                                            
 1950    [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC       
 1951               2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,     
 1952               May 2017, <https://www.rfc-editor.org/info/rfc8174>.         
 1953                                                                            
 1954    [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol   
 1955               Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,   
 1956               <https://www.rfc-editor.org/info/rfc8446>.                   
 1957                                                                            
 1958    [WebSocket]                                                             
 1959               Fette, I. and A. Melnikov, "The WebSocket Protocol",         
 1960               RFC 6455, DOI 10.17487/RFC6455, December 2011,               
 1961               <https://www.rfc-editor.org/info/rfc6455>.                   
 1962                                                                            
 1963 15.2.  Informative References                                              
 1964                                                                            
 1965    [AltSvc]   Nottingham, M., McManus, P., and J. Reschke, "HTTP           
 1966               Alternative Services", RFC 7838, DOI 10.17487/RFC7838,       
 1967               April 2016, <https://www.rfc-editor.org/info/rfc7838>.       
 1968                                                                            
 1969    [ANAME-DNS-RR]                                                          
 1970               Finch, T., Hunt, E., van Dijk, P., Eden, A., and W.          
 1971               Mekking, "Address-specific DNS aliases (ANAME)", Work in     
 1972               Progress, Internet-Draft, draft-ietf-dnsop-aname-04, 8       
 1973               July 2019, <https://datatracker.ietf.org/doc/html/draft-     
 1974               ietf-dnsop-aname-04>.                                        
 1975                                                                            
 1976    [BIND-CHECK-NAMES]                                                      
 1977               Internet Systems Consortium, "BIND v9.19.11 Configuration    
 1978               Reference: "check-names"", September 2023,                   
 1979               <https://bind9.readthedocs.io/en/v9.19.11/                   
 1980               reference.html#namedconf-statement-check-names>.             
 1981                                                                            
 1982    [DNAME]    Rose, S. and W. Wijngaards, "DNAME Redirection in the        
 1983               DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,             
 1984               <https://www.rfc-editor.org/info/rfc6672>.                   
 1985                                                                            
 1986    [DNSTerm]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS             
 1987               Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,       
 1988               January 2019, <https://www.rfc-editor.org/info/rfc8499>.     
 1989                                                                            
 1990    [ECH]      Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS    
 1991               Encrypted Client Hello", Work in Progress, Internet-Draft,   
 1992               draft-ietf-tls-esni-17, 9 October 2023,                      
 1993               <https://datatracker.ietf.org/doc/html/draft-ietf-tls-       
 1994               esni-17>.                                                    
 1995                                                                            
 1996    [FETCH]    WHATWG, "Fetch Living Standard", October 2023,               
 1997               <https://fetch.spec.whatwg.org/>.                            
 1998                                                                            
 1999    [FETCH-WEBSOCKETS]                                                      
 2000               WHATWG, "WebSockets Living Standard", September 2023,        
 2001               <https://websockets.spec.whatwg.org/>.                       
 2002                                                                            
 2003    [HSTS]     Hodges, J., Jackson, C., and A. Barth, "HTTP Strict          
 2004               Transport Security (HSTS)", RFC 6797,                        
 2005               DOI 10.17487/RFC6797, November 2012,                         
 2006               <https://www.rfc-editor.org/info/rfc6797>.                   
 2007                                                                            
 2008    [HTTP-DNS-RR]                                                           
 2009               Bellis, R., "A DNS Resource Record for HTTP", Work in        
 2010               Progress, Internet-Draft, draft-bellis-dnsop-http-record-    
 2011               00, 3 November 2018,                                         
 2012               <https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-   
 2013               http-record-00>.                                             
 2014                                                                            
 2015    [HTTP/3]   Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,   
 2016               June 2022, <https://www.rfc-editor.org/info/rfc9114>.        
 2017                                                                            
 2018    [RFC1912]  Barr, D., "Common DNS Operational and Configuration          
 2019               Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996,      
 2020               <https://www.rfc-editor.org/info/rfc1912>.                   
 2021                                                                            
 2022    [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,               
 2023               DOI 10.17487/RFC6454, December 2011,                         
 2024               <https://www.rfc-editor.org/info/rfc6454>.                   
 2025                                                                            
 2026    [SRV]      Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for     
 2027               specifying the location of services (DNS SRV)", RFC 2782,    
 2028               DOI 10.17487/RFC2782, February 2000,                         
 2029               <https://www.rfc-editor.org/info/rfc2782>.                   
 2030                                                                            
 2031    [URI]      Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform     
 2032               Resource Identifier (URI): Generic Syntax", STD 66,          
 2033               RFC 3986, DOI 10.17487/RFC3986, January 2005,                
 2034               <https://www.rfc-editor.org/info/rfc3986>.                   
 2035                                                                            
 2036 Appendix A.  Decoding Text in Zone Files                                   
 2037                                                                            
 2038    DNS zone files are capable of representing arbitrary octet sequences    
 2039    in basic ASCII text, using various delimiters and encodings,            
 2040    according to an algorithm defined in Section 5.1 of [RFC1035].  The     
 2041    following summarizes some allowed inputs to that algorithm, using       
 2042    ABNF:                                                                   
 2043                                                                            
 2044    ; non-special is VCHAR minus DQUOTE, ";", "(", ")", and "\".            
 2045    non-special = %x21 / %x23-27 / %x2A-3A / %x3C-5B / %x5D-7E              
 2046    ; non-digit is VCHAR minus DIGIT.                                       
 2047    non-digit   = %x21-2F / %x3A-7E                                         
 2048    ; dec-octet is a number 0-255 as a three-digit decimal number.          
 2049    dec-octet   = ( "0" / "1" ) 2DIGIT /                                    
 2050                  "2" ( ( %x30-34 DIGIT ) / ( "5" %x30-35 ) )               
 2051    escaped     = "\" ( non-digit / dec-octet )                             
 2052    contiguous  = 1*( non-special / escaped )                               
 2053    quoted      = DQUOTE *( contiguous / ( ["\"] WSP ) ) DQUOTE             
 2054    char-string = contiguous / quoted                                       
 2055                                                                            
 2056    The decoding algorithm allows char-string to represent any *OCTET,      
 2057    using quoting to group values (e.g., those with internal whitespace),   
 2058    and escaping to represent each non-printable octet as a single          
 2059    escaped sequence.  In this document, this algorithm is referred to as   
 2060    "character-string decoding", because Section 5.1 of [RFC1035] uses      
 2061    this algorithm to produce a <character-string>.  Note that while the    
 2062    length of a <character-string> is limited to 255 octets, the            
 2063    character-string decoding algorithm can produce output of any length.   
 2064                                                                            
 2065 A.1.  Decoding a Comma-Separated List                                      
 2066                                                                            
 2067    In order to represent lists of items in zone files, this                
 2068    specification uses comma-separated lists.  When the allowed items in    
 2069    the list cannot contain "," or "\", this is trivial.  (For              
 2070    simplicity, empty items are not allowed.)  A value-list parser that     
 2071    splits on "," and prohibits items containing "\" is sufficient to       
 2072    comply with all requirements in this document.  This corresponds to     
 2073    the simple-comma-separated syntax:                                      
 2074                                                                            
 2075    ; item-allowed is OCTET minus "," and "\".                              
 2076    item-allowed           = %x00-2B / %x2D-5B / %x5D-FF                    
 2077    simple-item            = 1*item-allowed                                 
 2078    simple-comma-separated = [simple-item *("," simple-item)]               
 2079                                                                            
 2080    For implementations that allow "," and "\" in item values, the          
 2081    following escaping syntax applies:                                      
 2082                                                                            
 2083    item            = 1*OCTET                                               
 2084    escaped-item    = 1*(item-allowed / "\," / "\\")                        
 2085    comma-separated = [escaped-item *("," escaped-item)]                    
 2086                                                                            
 2087    Decoding of value-lists happens after character-string decoding.  For   
 2088    example, consider these char-string SvcParamValues:                     
 2089                                                                            
 2090    "part1,part2,part3\\,part4\\\\"                                         
 2091    part1\,\p\a\r\t2\044part3\092,part4\092\\                               
 2092                                                                            
 2093    These inputs are equivalent: character-string decoding either of them   
 2094    would produce the same value:                                           
 2095                                                                            
 2096    part1,part2,part3\,part4\\                                              
 2097                                                                            
 2098    Applying comma-separated list decoding to this value would produce a    
 2099    list of three items:                                                    
 2100                                                                            
 2101    part1                                                                   
 2102    part2                                                                   
 2103    part3,part4\                                                            
 2104                                                                            
 2105 Appendix B.  HTTP Mapping Summary                                          
 2106                                                                            
 2107    This table serves as a non-normative summary of the HTTP mapping for    
 2108    SVCB (Section 9).  Future protocol mappings may provide a similar       
 2109    summary table.                                                          
 2110                                                                            
 2111             +--------------------------+----------------------+            
 2112             | *Mapped scheme*          | "https"              |            
 2113             +--------------------------+----------------------+            
 2114             | *Other affected schemes* | "http", "wss", "ws", |            
 2115             |                          | (other HTTP-based)   |            
 2116             +--------------------------+----------------------+            
 2117             | *RR type*                | HTTPS (65)           |            
 2118             +--------------------------+----------------------+            
 2119             | *Name prefix*            | None for port 443,   |            
 2120             |                          | else _$PORT._https   |            
 2121             +--------------------------+----------------------+            
 2122             | *Automatically mandatory | port, no-default-    |            
 2123             | keys*                    | alpn                 |            
 2124             +--------------------------+----------------------+            
 2125             | *SvcParam defaults*      | alpn: ["http/1.1"]   |            
 2126             +--------------------------+----------------------+            
 2127             | *Special behaviors*      | Upgrade from HTTP to |            
 2128             |                          | HTTPS                |            
 2129             +--------------------------+----------------------+            
 2130             | *Keys that records must  | None                 |            
 2131             | include*                 |                      |            
 2132             +--------------------------+----------------------+            
 2133                                                                            
 2134                                   Table 3                                  
 2135                                                                            
 2136 Appendix C.  Comparison with Alternatives                                  
 2137                                                                            
 2138    The SVCB and HTTPS RR types closely resemble, and are inspired by,      
 2139    some existing record types and proposals.  One complaint regarding      
 2140    all of the alternatives is that web clients have seemed                 
 2141    unenthusiastic about implementing them.  The hope here is that an       
 2142    extensible solution that solves multiple problems will overcome this    
 2143    inertia and have a path to achieve client implementation.               
 2144                                                                            
 2145 C.1.  Differences from the SRV RR Type                                     
 2146                                                                            
 2147    An SRV record [SRV] can perform a function similar to that of the       
 2148    SVCB record, informing a client to look in a different location for a   
 2149    service.  However, there are several differences:                       
 2150                                                                            
 2151    *  SRV records are typically mandatory, whereas SVCB is intended to     
 2152       be optional when used with pre-existing protocols.                   
 2153                                                                            
 2154    *  SRV records cannot instruct the client to switch or upgrade          
 2155       protocols, whereas SVCB can signal such an upgrade (e.g., to         
 2156       HTTP/2).                                                             
 2157                                                                            
 2158    *  SRV records are not extensible, whereas SVCB and HTTPS RRs can be    
 2159       extended with new parameters.                                        
 2160                                                                            
 2161    *  SRV records specify a "weight" for unbalanced randomized load        
 2162       balancing.  SVCB only supports balanced randomized load balancing,   
 2163       although weights could be added via a future SvcParam.               
 2164                                                                            
 2165 C.2.  Differences from the Proposed HTTP Record                            
 2166                                                                            
 2167    Unlike [HTTP-DNS-RR], this approach is extensible to cover Alt-Svc      
 2168    and Encrypted ClientHello use cases.  Like that proposal, this          
 2169    addresses the zone-apex CNAME challenge.                                
 2170                                                                            
 2171    Like that proposal, it remains necessary to continue to include         
 2172    address records at the zone apex for legacy clients.                    
 2173                                                                            
 2174 C.3.  Differences from the Proposed ANAME Record                           
 2175                                                                            
 2176    Unlike [ANAME-DNS-RR], this approach is extensible to cover Alt-Svc     
 2177    and Encrypted ClientHello use cases.  This approach also does not       
 2178    require any changes or special handling on either authoritative or      
 2179    primary servers, beyond optionally returning in-bailiwick additional    
 2180    records.                                                                
 2181                                                                            
 2182    Like that proposal, this addresses the zone-apex CNAME challenge for    
 2183    clients that implement this.                                            
 2184                                                                            
 2185    However, with this SVCB proposal, it remains necessary to continue to   
 2186    include address records at the zone apex for legacy clients.  If        
 2187    deployment of this standard is successful, the number of legacy         
 2188    clients will fall over time.  As the number of legacy clients           
 2189    declines, the operational effort required to serve these users          
 2190    without the benefit of SVCB indirection should fall.  Server            
 2191    operators can easily observe how much traffic reaches this legacy       
 2192    endpoint and may remove the apex's address records if the observed      
 2193    legacy traffic has fallen to negligible levels.                         
 2194                                                                            
 2195 C.4.  Comparison with Separate RR Types for AliasMode and ServiceMode      
 2196                                                                            
 2197    Abstractly, functions of AliasMode and ServiceMode are independent,     
 2198    so it might be tempting to specify them as separate RR types.           
 2199    However, this would result in serious performance impairment, because   
 2200    clients cannot rely on their recursive resolver to follow SVCB          
 2201    aliases (unlike CNAME).  Thus, clients would have to issue queries      
 2202    for both RR types in parallel, potentially at each step of the alias    
 2203    chain.  Recursive resolvers that implement the specification would,     
 2204    upon receipt of a ServiceMode query, emit both a ServiceMode query      
 2205    and an AliasMode query to the authoritative DNS server.  Thus,          
 2206    splitting the RR type would double, or in some cases triple, the load   
 2207    on clients and servers, and would not reduce implementation             
 2208    complexity.                                                             
 2209                                                                            
 2210 Appendix D.  Test Vectors                                                  
 2211                                                                            
 2212    These test vectors only contain the RDATA portion of SVCB/HTTPS         
 2213    records in presentation format, generic format [RFC3597], and wire      
 2214    format.  The wire format uses hexadecimal (\xNN) for each non-ASCII     
 2215    byte.  As the wire format is long, it is broken into several lines.     
 2216                                                                            
 2217 D.1.  AliasMode                                                            
 2218                                                                            
 2219    example.com.   HTTPS   0 foo.example.com.                               
 2220                                                                            
 2221    \# 19 (                                                                 
 2222    00 00                                              ; priority           
 2223    03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target             
 2224    )                                                                       
 2225                                                                            
 2226    \x00\x00                                           # priority           
 2227    \x03foo\x07example\x03com\x00                      # target             
 2228                                                                            
 2229                             Figure 2: AliasMode                            
 2230                                                                            

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.

 2231 D.2.  ServiceMode                                                          
 2232                                                                            
 2233    example.com.   SVCB   1 .                                               
 2234                                                                            
 2235    \# 3 (                                                                  
 2236    00 01      ; priority                                                   
 2237    00         ; target (root label)                                        
 2238    )                                                                       
 2239                                                                            
 2240    \x00\x01   # priority                                                   
 2241    \x00       # target (root label)                                        
 2242                                                                            
 2243                         Figure 3: TargetName Is "."                        
 2244                                                                            
 2245    example.com.   SVCB   16 foo.example.com. port=53                       
 2246                                                                            
 2247    \# 25 (                                                                 
 2248    00 10                                              ; priority           
 2249    03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target             
 2250    00 03                                              ; key 3              
 2251    00 02                                              ; length 2           
 2252    00 35                                              ; value              
 2253    )                                                                       
 2254                                                                            
 2255    \x00\x10                                           # priority           
 2256    \x03foo\x07example\x03com\x00                      # target             
 2257    \x00\x03                                           # key 3              
 2258    \x00\x02                                           # length 2           
 2259    \x00\x35                                           # value              
 2260                                                                            
 2261                          Figure 4: Specifies a Port                        
 2262                                                                            
 2263    example.com.   SVCB   1 foo.example.com. key667=hello                   
 2264                                                                            
 2265    \# 28 (                                                                 
 2266    00 01                                              ; priority           
 2267    03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target             
 2268    02 9b                                              ; key 667            
 2269    00 05                                              ; length 5           
 2270    68 65 6c 6c 6f                                     ; value              
 2271    )                                                                       
 2272                                                                            
 2273    \x00\x01                                           # priority           
 2274    \x03foo\x07example\x03com\x00                      # target             
 2275    \x02\x9b                                           # key 667            
 2276    \x00\x05                                           # length 5           
 2277    hello                                              # value              
 2278                                                                            
 2279                  Figure 5: A Generic Key and Unquoted Value                
 2280                                                                            
 2281    example.com.   SVCB   1 foo.example.com. key667="hello\210qoo"          
 2282                                                                            
 2283    \# 32 (                                                                 
 2284    00 01                                              ; priority           
 2285    03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target             
 2286    02 9b                                              ; key 667            
 2287    00 09                                              ; length 9           
 2288    68 65 6c 6c 6f d2 71 6f 6f                         ; value              
 2289    )                                                                       
 2290                                                                            
 2291    \x00\x01                                           # priority           
 2292    \x03foo\x07example\x03com\x00                      # target             
 2293    \x02\x9b                                           # key 667            
 2294    \x00\x09                                           # length 9           
 2295    hello\xd2qoo                                       # value              
 2296                                                                            
 2297        Figure 6: A Generic Key and Quoted Value with a Decimal Escape      
 2298                                                                            
 2299    example.com.   SVCB   1 foo.example.com. (                              
 2300                          ipv6hint="2001:db8::1,2001:db8::53:1"             
 2301                          )                                                 
 2302                                                                            
 2303    \# 55 (                                                                 
 2304    00 01                                              ; priority           
 2305    03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target             
 2306    00 06                                              ; key 6              
 2307    00 20                                              ; length 32          
 2308    20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01    ; first address      
 2309    20 01 0d b8 00 00 00 00 00 00 00 00 00 53 00 01    ; second address     
 2310    )                                                                       
 2311                                                                            
 2312    \x00\x01                                           # priority           
 2313    \x03foo\x07example\x03com\x00                      # target             
 2314    \x00\x06                                           # key 6              
 2315    \x00\x20                                           # length 32          
 2316    \x20\x01\x0d\xb8\x00\x00\x00\x00                                        
 2317         \x00\x00\x00\x00\x00\x00\x00\x01              # first address      
 2318    \x20\x01\x0d\xb8\x00\x00\x00\x00                                        
 2319         \x00\x00\x00\x00\x00\x53\x00\x01              # second address     
 2320                                                                            
 2321                       Figure 7: Two Quoted IPv6 Hints                      
 2322                                                                            
 2323    example.com.   SVCB   1 example.com. (                                  
 2324                            ipv6hint="2001:db8:122:344::192.0.2.33"         
 2325                            )                                               
 2326    \# 35 (                                                                 
 2327    00 01                                              ; priority           
 2328    07 65 78 61 6d 70 6c 65 03 63 6f 6d 00             ; target             
 2329    00 06                                              ; key 6              
 2330    00 10                                              ; length 16          
 2331    20 01 0d b8 01 22 03 44 00 00 00 00 c0 00 02 21    ; address            
 2332    )                                                                       
 2333                                                                            
 2334    \x00\x01                                           # priority           
 2335    \x07example\x03com\x00                             # target             
 2336    \x00\x06                                           # key 6              
 2337    \x00\x10                                           # length 16          
 2338    \x20\x01\x0d\xb8\x01\x22\x03\x44                                        
 2339         \x00\x00\x00\x00\xc0\x00\x02\x21              # address            
 2340                                                                            
 2341            Figure 8: An IPv6 Hint Using the Embedded IPv4 Syntax           
 2342                                                                            
 2343    example.com.   SVCB   16 foo.example.org. (                             
 2344                          alpn=h2,h3-19 mandatory=ipv4hint,alpn             
 2345                          ipv4hint=192.0.2.1                                
 2346                          )                                                 
 2347                                                                            
 2348    \# 48 (                                                                 
 2349    00 10                                              ; priority           
 2350    03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target             
 2351    00 00                                              ; key 0              
 2352    00 04                                              ; param length 4     
 2353    00 01                                              ; value: key 1       
 2354    00 04                                              ; value: key 4       
 2355    00 01                                              ; key 1              
 2356    00 09                                              ; param length 9     
 2357    02                                                 ; alpn length 2      
 2358    68 32                                              ; alpn value         
 2359    05                                                 ; alpn length 5      
 2360    68 33 2d 31 39                                     ; alpn value         
 2361    00 04                                              ; key 4              
 2362    00 04                                              ; param length 4     
 2363    c0 00 02 01                                        ; param value        
 2364    )                                                                       
 2365                                                                            
 2366    \x00\x10                                           # priority           
 2367    \x03foo\x07example\x03org\x00                      # target             
 2368    \x00\x00                                           # key 0              
 2369    \x00\x04                                           # param length 4     
 2370    \x00\x01                                           # value: key 1       
 2371    \x00\x04                                           # value: key 4       
 2372    \x00\x01                                           # key 1              
 2373    \x00\x09                                           # param length 9     
 2374    \x02                                               # alpn length 2      
 2375    h2                                                 # alpn value         
 2376    \x05                                               # alpn length 5      
 2377    h3-19                                              # alpn value         
 2378    \x00\x04                                           # key 4              
 2379    \x00\x04                                           # param length 4     
 2380    \xc0\x00\x02\x01                                   # param value        
 2381                                                                            
 2382         Figure 9: SvcParamKey Ordering Is Arbitrary in Presentation        
 2383                       Format but Sorted in Wire Format                     
 2384                                                                            
 2385    example.com.   SVCB   16 foo.example.org. alpn="f\\\\oo\\,bar,h2"       
 2386    example.com.   SVCB   16 foo.example.org. alpn=f\\\092oo\092,bar,h2     
 2387                                                                            
 2388    \# 35 (                                                                 
 2389    00 10                                              ; priority           
 2390    03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target             
 2391    00 01                                              ; key 1              
 2392    00 0c                                              ; param length 12    
 2393    08                                                 ; alpn length 8      
 2394    66 5c 6f 6f 2c 62 61 72                            ; alpn value         
 2395    02                                                 ; alpn length 2      
 2396    68 32                                              ; alpn value         
 2397    )                                                                       
 2398                                                                            
 2399    \x00\x10                                           # priority           
 2400    \x03foo\x07example\x03org\x00                      # target             
 2401    \x00\x01                                           # key 1              
 2402    \x00\x0c                                           # param length 12    
 2403    \x08                                               # alpn length 8      
 2404    f\oo,bar                                           # alpn value         
 2405    \x02                                               # alpn length 2      
 2406    h2                                                 # alpn value         
 2407                                                                            
 2408       Figure 10: An "alpn" Value with an Escaped Comma and an Escaped      
 2409                    Backslash in Two Presentation Formats                   
 2410                                                                            
 2411 D.3.  Failure Cases                                                        
 2412                                                                            
 2413    This subsection contains test vectors that are not compliant with       
 2414    this document.  The various reasons for non-compliance are explained    
 2415    with each example.                                                      
 2416                                                                            
 2417    example.com.   SVCB   1 foo.example.com. (                              
 2418                           key123=abc key123=def                            
 2419                           )                                                
 2420                                                                            
 2421            Figure 11: Multiple Instances of the Same SvcParamKey           
 2422                                                                            
 2423    example.com.   SVCB   1 foo.example.com. mandatory                      
 2424    example.com.   SVCB   1 foo.example.com. alpn                           
 2425    example.com.   SVCB   1 foo.example.com. port                           
 2426    example.com.   SVCB   1 foo.example.com. ipv4hint                       
 2427    example.com.   SVCB   1 foo.example.com. ipv6hint                       
 2428                                                                            
 2429           Figure 12: Missing SvcParamValues That Must Be Non-Empty         
 2430                                                                            
 2431    example.com.   SVCB   1 foo.example.com. no-default-alpn=abc            
 2432                                                                            
 2433       Figure 13: The "no-default-alpn" SvcParamKey Value Must Be Empty     
 2434                                                                            
 2435    example.com.   SVCB   1 foo.example.com. mandatory=key123               
 2436                                                                            
 2437                  Figure 14: A Mandatory SvcParam Is Missing                
 2438                                                                            
 2439    example.com.   SVCB   1 foo.example.com. mandatory=mandatory            
 2440                                                                            
 2441        Figure 15: The "mandatory" SvcParamKey Must Not Be Included in      
 2442                              the Mandatory List                            
 2443                                                                            
 2444    example.com.   SVCB   1 foo.example.com. (                              
 2445                          mandatory=key123,key123 key123=abc                
 2446                          )                                                 
 2447                                                                            
 2448         Figure 16: Multiple Instances of the Same SvcParamKey in the       
 2449                                Mandatory List                              
 2450                                                                            
 2451 Acknowledgments and Related Proposals                                      
 2452                                                                            
 2453    Over the years, IETF participants have proposed a wide range of         
 2454    solutions to the "CNAME at the zone apex" challenge, including          
 2455    [HTTP-DNS-RR], [ANAME-DNS-RR], and others.  The authors are grateful    
 2456    for their work to elucidate the problem and identify promising          
 2457    strategies to address it, some of which are reflected in this           
 2458    document.                                                               
 2459                                                                            
 2460    Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thomson, Lucas     
 2461    Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, David   
 2462    Benjamin, Mark Andrews, Emily Stark, Eric Orth, Kyle Rose, Craig        
 2463    Taylor, Dan McArdle, Brian Dickson, Willem Toorop, Pieter Lexis,        
 2464    Puneet Sood, Olivier Poitrey, Mashooq Muhaimen, Tom Carpay, and many    
 2465    others for their feedback and suggestions on this document.             
 2466                                                                            
 2467 Authors' Addresses                                                         
 2468                                                                            
 2469    Ben Schwartz                                                            
 2470    Meta Platforms, Inc.                                                    
 2471    Email: ietf@bemasc.net                                                  
 2472                                                                            
 2473                                                                            
 2474    Mike Bishop                                                             
 2475    Akamai Technologies                                                     
 2476    Email: mbishop@evequefou.be                                             
 2477                                                                            
 2478                                                                            
 2479    Erik Nygren                                                             
 2480    Akamai Technologies                                                     
 2481    Email: erik+ietf@nygren.org                                             
 2482                                                                            
appendix-D.2 Shulhan(Technical Erratum #7871) [Rejected]
based on outdated version
example.com.   SVCB   1 foo.example.com. key667="hello\210qoo"

\# 32 (
00 01                                              ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
02 9b                                              ; key 667
00 09                                              ; length 9
68 65 6c 6c 6f d2 71 6f 6f                         ; value
)

\x00\x01                                           # priority
\x03foo\x07example\x03com\x00                      # target
\x02\x9b                                           # key 667
\x00\x09                                           # length 9
hello\xd2qoo                                       # value
It should say:
example.com.   SVCB   1 foo.example.com. key667="hello\210qoo"

\# 32 (
00 01                                              ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
02 9b                                              ; key 667
00 09                                              ; length 9
68 65 6c 6c 6f 88 71 6f 6f                         ; value
)

\x00\x01                                           # priority
\x03foo\x07example\x03com\x00                      # target
\x02\x9b                                           # key 667
\x00\x09                                           # length 9
hello\x88qoo                                       # value

Original report:
The escaped octal number "\210" when encoded to hexadecimal should be
"88" or "\x88", NOT "d2" or "\xd2".

The "d2" or "\xd2" is hexadecimal value for decimal number "210".


WK Edit: I am rejecting this Errata -- the display format
(key667="hello\210qoo") is encoded using the DNS RFC1035 syntax, which
specifies:
\DDD            where each D is a digit is the octet corresponding to
the decimal number described by DDD.

This is, um, surprising to many, and a relatively common source of
issues in the DNS parsing world.

I encourage future updates of the RFC to include a "footnote" /
parenthetical pointing this out...
--VERIFIER NOTES--
I am rejecting this Errata -- the display format
(key667="hello\210qoo") is encoded using the DNS RFC1035 syntax, which
specifies:
\DDD where each D is a digit is the octet corresponding to
the decimal number described by DDD.

This is, um, surprising to many, and a relatively common source of
issues in the DNS parsing world.

I encourage future updates of the RFC to include a "footnote" /
parenthetical pointing this out...