idnits 2.17.1 draft-ietf-dnsop-svcb-https-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([HTTP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 May 2022) is 702 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-14 -- Possible downref: Normative reference to a draft: ref. 'HTTP' ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 7871 -- Obsolete informational reference (is this intentional?): RFC 8499 (ref. 'DNSTerm') (Obsoleted by RFC 9499) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group B. Schwartz 3 Internet-Draft Google 4 Intended status: Standards Track M. Bishop 5 Expires: 25 November 2022 E. Nygren 6 Akamai Technologies 7 24 May 2022 9 Service binding and parameter specification via the DNS (DNS SVCB and 10 HTTPS RRs) 11 draft-ietf-dnsop-svcb-https-10 13 Abstract 15 This document specifies the "SVCB" and "HTTPS" DNS resource record 16 (RR) types to facilitate the lookup of information needed to make 17 connections to network services, such as for HTTP origins. SVCB 18 records allow a service to be provided from multiple alternative 19 endpoints, each with associated parameters (such as transport 20 protocol configuration and keys for encrypting the TLS ClientHello). 21 They 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 [HTTP]. 23 By providing more information to the client before it attempts to 24 establish a connection, these records offer potential benefits to 25 both performance and privacy. 27 TO BE REMOVED: This document is being collaborated on in Github at: 28 https://github.com/MikeBishop/dns-alt-svc 29 (https://github.com/MikeBishop/dns-alt-svc). The most recent working 30 version of the document, open issues, etc. should all be available 31 there. The authors (gratefully) accept pull requests. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 25 November 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Goals of the SVCB RR . . . . . . . . . . . . . . . . . . 5 68 1.2. Overview of the SVCB RR . . . . . . . . . . . . . . . . . 6 69 1.3. Parameter for Encrypted ClientHello . . . . . . . . . . . 7 70 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 71 2. The SVCB record type . . . . . . . . . . . . . . . . . . . . 7 72 2.1. Zone file presentation format . . . . . . . . . . . . . . 8 73 2.2. RDATA wire format . . . . . . . . . . . . . . . . . . . . 9 74 2.3. SVCB query names . . . . . . . . . . . . . . . . . . . . 10 75 2.4. Interpretation . . . . . . . . . . . . . . . . . . . . . 11 76 2.4.1. SvcPriority . . . . . . . . . . . . . . . . . . . . . 11 77 2.4.2. AliasMode . . . . . . . . . . . . . . . . . . . . . . 11 78 2.4.3. ServiceMode . . . . . . . . . . . . . . . . . . . . . 13 79 2.5. Special handling of "." in TargetName . . . . . . . . . . 13 80 2.5.1. AliasMode . . . . . . . . . . . . . . . . . . . . . . 13 81 2.5.2. ServiceMode . . . . . . . . . . . . . . . . . . . . . 13 82 3. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 14 83 3.1. Handling resolution failures . . . . . . . . . . . . . . 15 84 3.2. Clients using a Proxy . . . . . . . . . . . . . . . . . . 16 85 4. DNS Server Behavior . . . . . . . . . . . . . . . . . . . . . 17 86 4.1. Authoritative servers . . . . . . . . . . . . . . . . . . 17 87 4.2. Recursive resolvers . . . . . . . . . . . . . . . . . . . 17 88 4.2.1. DNS64 . . . . . . . . . . . . . . . . . . . . . . . . 18 89 4.3. General requirements . . . . . . . . . . . . . . . . . . 18 90 4.4. EDNS Client Subnet (ECS) . . . . . . . . . . . . . . . . 19 91 5. Performance optimizations . . . . . . . . . . . . . . . . . . 19 92 5.1. Optimistic pre-connection and connection reuse . . . . . 20 93 5.2. Generating and using incomplete responses . . . . . . . . 20 94 6. SVCB-compatible . . . . . . . . . . . . . . . . . . . . . . . 21 95 7. Initial SvcParamKeys . . . . . . . . . . . . . . . . . . . . 21 96 7.1. "alpn" and "no-default-alpn" . . . . . . . . . . . . . . 22 97 7.1.1. Representation . . . . . . . . . . . . . . . . . . . 22 98 7.1.2. Use . . . . . . . . . . . . . . . . . . . . . . . . . 23 99 7.2. "port" . . . . . . . . . . . . . . . . . . . . . . . . . 24 100 7.3. "ech" . . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 7.4. "ipv4hint" and "ipv6hint" . . . . . . . . . . . . . . . . 25 102 7.5. "mandatory" . . . . . . . . . . . . . . . . . . . . . . . 26 103 8. ServiceMode RR compatibility and mandatory keys . . . . . . . 26 104 9. Using Service Bindings with HTTP . . . . . . . . . . . . . . 27 105 9.1. Query names for HTTPS RRs . . . . . . . . . . . . . . . . 27 106 9.2. Comparison with Alt-Svc . . . . . . . . . . . . . . . . . 28 107 9.2.1. ALPN usage . . . . . . . . . . . . . . . . . . . . . 28 108 9.2.2. Untrusted channel . . . . . . . . . . . . . . . . . . 28 109 9.2.3. Cache lifetime . . . . . . . . . . . . . . . . . . . 28 110 9.2.4. Granularity . . . . . . . . . . . . . . . . . . . . . 29 111 9.3. Interaction with Alt-Svc . . . . . . . . . . . . . . . . 29 112 9.4. Requiring Server Name Indication . . . . . . . . . . . . 30 113 9.5. HTTP Strict Transport Security . . . . . . . . . . . . . 30 114 9.6. Use of HTTPS RRs in other protocols . . . . . . . . . . . 31 115 10. SVCB/HTTPS RR parameter for ECH configuration . . . . . . . . 32 116 10.1. Client behavior . . . . . . . . . . . . . . . . . . . . 32 117 10.2. Deployment considerations . . . . . . . . . . . . . . . 32 118 11. Zone Structures . . . . . . . . . . . . . . . . . . . . . . . 33 119 11.1. Structuring zones for flexibility . . . . . . . . . . . 33 120 11.2. Structuring zones for performance . . . . . . . . . . . 33 121 11.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 34 122 11.3.1. Protocol enhancements . . . . . . . . . . . . . . . 34 123 11.3.2. Apex aliasing . . . . . . . . . . . . . . . . . . . 34 124 11.3.3. Parameter binding . . . . . . . . . . . . . . . . . 35 125 11.3.4. Multi-CDN . . . . . . . . . . . . . . . . . . . . . 35 126 11.3.5. Non-HTTP uses . . . . . . . . . . . . . . . . . . . 37 127 12. Interaction with other standards . . . . . . . . . . . . . . 38 128 13. Security Considerations . . . . . . . . . . . . . . . . . . . 38 129 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 39 130 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 131 15.1. SVCB RRType . . . . . . . . . . . . . . . . . . . . . . 39 132 15.2. HTTPS RRType . . . . . . . . . . . . . . . . . . . . . . 40 133 15.3. New registry for Service Parameters . . . . . . . . . . 40 134 15.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . 40 135 15.3.2. Initial contents . . . . . . . . . . . . . . . . . . 41 136 15.4. Other registry updates . . . . . . . . . . . . . . . . . 43 137 16. Acknowledgments and Related Proposals . . . . . . . . . . . . 43 138 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 139 17.1. Normative References . . . . . . . . . . . . . . . . . . 43 140 17.2. Informative References . . . . . . . . . . . . . . . . . 46 141 Appendix A. Decoding text in zone files . . . . . . . . . . . . 47 142 A.1. Decoding a comma-separated list . . . . . . . . . . . . . 48 143 Appendix B. HTTP Mapping Summary . . . . . . . . . . . . . . . . 49 144 Appendix C. Comparison with alternatives . . . . . . . . . . . . 50 145 C.1. Differences from the SRV RR type . . . . . . . . . . . . 50 146 C.2. Differences from the proposed HTTP record . . . . . . . . 50 147 C.3. Differences from the proposed ANAME record . . . . . . . 50 148 C.4. Comparison with separate RR types for AliasMode and 149 ServiceMode . . . . . . . . . . . . . . . . . . . . . . . 51 150 Appendix D. Test vectors . . . . . . . . . . . . . . . . . . . . 51 151 D.1. AliasMode . . . . . . . . . . . . . . . . . . . . . . . . 51 152 D.2. ServiceMode . . . . . . . . . . . . . . . . . . . . . . . 51 153 D.3. Failure cases . . . . . . . . . . . . . . . . . . . . . . 56 154 Appendix E. Change history . . . . . . . . . . . . . . . . . . . 57 155 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 157 1. Introduction 159 The SVCB ("Service Binding") and HTTPS RRs provide clients with 160 complete instructions for access to a service. This information 161 enables improved performance and privacy by avoiding transient 162 connections to a suboptimal default server, negotiating a preferred 163 protocol, and providing relevant public keys. 165 For example, HTTP clients currently resolve only A and/or AAAA 166 records for the origin hostname, learning only its IP addresses. If 167 an HTTP client learns more about the origin before connecting, it may 168 be able to upgrade "http" URLs to "https", enable HTTP/3 or Encrypted 169 ClientHello [ECH], or switch to an operationally preferable endpoint. 170 It is highly desirable to minimize the number of round-trips and 171 lookups required to learn this additional information. 173 The SVCB and HTTPS RRs also help when the operator of a service 174 wishes to delegate operational control to one or more other domains, 175 e.g. delegating the origin "https://example.com" to a service 176 operator endpoint at "svc.example.net". While this case can 177 sometimes be handled by a CNAME, that does not cover all use-cases. 178 CNAME is also inadequate when the service operator needs to provide a 179 bound collection of consistent configuration parameters through the 180 DNS (such as network location, protocol, and keying information). 182 This document first describes the SVCB RR as a general-purpose 183 resource record that can be applied directly and efficiently to a 184 wide range of services (Section 2). It also describes the rules for 185 defining other SVCB-compatible RR types (Section 6), starting with 186 the HTTPS RR type (Section 9), which provides improved efficiency and 187 convenience with HTTP by avoiding the need for an Attrleaf label 188 [Attrleaf] (Section 9.1). 190 The SVCB RR has two modes: 1) "AliasMode", which simply delegates 191 operational control for a resource; 2) "ServiceMode", which binds 192 together configuration information for a service endpoint. 193 ServiceMode provides additional key=value parameters within each 194 RDATA set. 196 1.1. Goals of the SVCB RR 198 The goal of the SVCB RR is to allow clients to resolve a single 199 additional DNS RR in a way that: 201 * Provides alternative endpoints that are authoritative for the 202 service, along with parameters associated with each of these 203 endpoints. 205 * Does not assume that all alternative endpoints have the same 206 parameters or capabilities, or are even operated by the same 207 entity. This is important, as DNS does not provide any way to tie 208 together multiple RRSets for the same name. For example, if 209 www.example.com is a CNAME alias that switches between one of 210 three CDNs or hosting environments, successive queries for that 211 name may return records that correspond to different environments. 213 * Enables CNAME-like functionality at a zone apex (such as 214 "example.com") for participating protocols, and generally enables 215 delegation of operational authority for an origin within the DNS 216 to an alternate name. 218 Additional goals specific to HTTPS RRs and the HTTP use-cases 219 include: 221 * Connect directly to HTTP/3 (QUIC transport) alternative endpoints 222 [HTTP3] 224 * Obtain the Encrypted ClientHello [ECH] keys associated with an 225 alternative endpoint 227 * Support non-default TCP and UDP ports 229 * Enable SRV-like benefits (e.g. apex delegation, as mentioned 230 above) for HTTP, where SRV [SRV] has not been widely adopted 232 * Provide an HSTS-like indication [HSTS] signaling that the "https" 233 scheme should be used instead of "http" for all HTTP requests to 234 this host and port (see Section 9.5). 236 1.2. Overview of the SVCB RR 238 This subsection briefly describes the SVCB RR with forward references 239 to the full exposition of each component. (As mentioned above, this 240 all applies equally to the HTTPS RR which shares the same encoding, 241 format, and high-level semantics.) 243 The SVCB RR has two modes: AliasMode (Section 2.4.2), which aliases a 244 name to another name, and ServiceMode (Section 2.4.3), which provides 245 connection information bound to a service endpoint domain. Placing 246 both forms in a single RR type allows clients to fetch the relevant 247 information with a single query (Section 2.3). 249 The SVCB RR has two required fields and one optional field. The 250 fields are: 252 1. SvcPriority (Section 2.4.1): The priority of this record 253 (relative to others, with lower values preferred). A value of 0 254 indicates AliasMode. 256 2. TargetName: The domain name of either the alias target (for 257 AliasMode) or the alternative endpoint (for ServiceMode). 259 3. SvcParams (optional): A list of key=value pairs describing the 260 alternative endpoint at TargetName (only used in ServiceMode and 261 otherwise ignored). Described in Section 2.1. 263 Cooperating DNS recursive resolvers will perform subsequent record 264 resolution (for SVCB, A, and AAAA records) and return them in the 265 Additional Section of the response (Section 4.2). Clients either use 266 responses included in the additional section returned by the 267 recursive resolver or perform necessary SVCB, A, and AAAA record 268 resolutions (Section 3). DNS authoritative servers can attach in- 269 bailiwick SVCB, A, AAAA, and CNAME records in the Additional 270 Section to responses for a SVCB query (Section 4.1). 272 In ServiceMode, the SvcParams of the SVCB RR provide an extensible 273 data model for describing alternative endpoints that are 274 authoritative for a service, along with parameters associated with 275 each of these alternative endpoints (Section 7). 277 For HTTP use-cases, the HTTPS RR (Section 9) enables many of the 278 benefits of Alt-Svc [AltSvc] without waiting for a full HTTP 279 connection initiation (multiple roundtrips) before learning of the 280 preferred alternative, and without necessarily revealing the user's 281 intended destination to all entities along the network path. 283 1.3. Parameter for Encrypted ClientHello 285 This document also defines a parameter for Encrypted ClientHello 286 [ECH] keys. See Section 10. 288 1.4. Terminology 290 Our terminology is based on the common case where the SVCB record is 291 used to access a resource identified by a URI whose authority field 292 contains a DNS hostname as the host. 294 * The "service" is the information source identified by the 295 authority and scheme of the URI, capable of providing access to 296 the resource. For "https" URIs, the "service" corresponds to an 297 "origin" [RFC6454]. 299 * The "service name" is the host portion of the authority. 301 * The "authority endpoint" is the authority's hostname and a port 302 number implied by the scheme or specified in the URI. 304 * An "alternative endpoint" is a hostname, port number, and other 305 associated instructions to the client on how to reach an instance 306 of service. 308 Additional DNS terminology intends to be consistent with [DNSTerm]. 310 SVCB is a contraction of "service binding". The SVCB RR, HTTPS RR, 311 and future RR types that share SVCB's formats and registry are 312 collectively known as SVCB-compatible RR types. The contraction 313 "SVCB" is also used to refer to this system as a whole. 315 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 316 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 317 "OPTIONAL" in this document are to be interpreted as described in BCP 318 14 [RFC2119] [RFC8174] when, and only when, they appear in all 319 capitals, as shown here. 321 2. The SVCB record type 323 The SVCB DNS resource record (RR) type (RR type 64) is used to locate 324 alternative endpoints for a service. 326 The algorithm for resolving SVCB records and associated address 327 records is specified in Section 3. 329 Other SVCB-compatible resource record types can also be defined as- 330 needed (see Section 6). In particular, the HTTPS RR (RR type 65) 331 provides special handling for the case of "https" origins as 332 described in Section 9. 334 SVCB RRs are extensible by a list of SvcParams, which are pairs 335 consisting of a SvcParamKey and a SvcParamValue. Each SvcParamKey 336 has a presentation name and a registered number. Values are in a 337 format specific to the SvcParamKey. Each SvcParam has a specified 338 presentation format (used in zone files) and wire encoding (e.g., 339 domain names, binary data, or numeric values). The initial 340 SvcParamKeys and their formats are defined in Section 7. 342 2.1. Zone file presentation format 344 The presentation format of the record ([RFC1035], 345 Section 5.1) has the form: 347 SvcPriority TargetName SvcParams 349 The SVCB record is defined specifically within the Internet ("IN") 350 Class ([RFC1035], Section 3.2.4). 352 SvcPriority is a number in the range 0-65535, TargetName is a 353 ([RFC1035], Section 5.1), and the SvcParams are a 354 whitespace-separated list, with each SvcParam consisting of a 355 SvcParamKey=SvcParamValue pair or a standalone SvcParamKey. 356 SvcParamKeys are subject to IANA control (Section 15.3). 358 Each SvcParamKey SHALL appear at most once in the SvcParams. In 359 presentation format, SvcParamKeys are lower-case alphanumeric 360 strings. Key names contain 1-63 characters from the ranges "a"-"z", 361 "0"-"9", and "-". In ABNF [RFC5234], 363 alpha-lc = %x61-7A ; a-z 364 SvcParamKey = 1*63(alpha-lc / DIGIT / "-") 365 SvcParam = SvcParamKey ["=" SvcParamValue] 366 SvcParamValue = char-string ; See Appendix A 367 value = *OCTET ; Value before key-specific parsing 369 The SvcParamValue is parsed using the character-string decoding 370 algorithm (Appendix A), producing a value. The value is then 371 validated and converted into wire-format in a manner specific to each 372 key. 374 When the optional "=" and SvcParamValue are omitted, the value is 375 interpreted as empty. 377 Arbitrary keys can be represented using the unknown-key presentation 378 format "keyNNNNN" where NNNNN is the numeric value of the key type 379 without leading zeros. A SvcParam in this form SHALL be parsed as 380 specified above, and the decoded value SHALL be used as its wire 381 format encoding. 383 For some SvcParamKeys, the value corresponds to a list or set of 384 items. Presentation formats for such keys SHOULD use a comma- 385 separated list (Appendix A.1). 387 SvcParams in presentation format MAY appear in any order, but keys 388 MUST NOT be repeated. 390 2.2. RDATA wire format 392 The RDATA for the SVCB RR consists of: 394 * a 2-octet field for SvcPriority as an integer in network byte 395 order. 397 * the uncompressed, fully-qualified TargetName, represented as a 398 sequence of length-prefixed labels as in Section 3.1 of [RFC1035]. 400 * the SvcParams, consuming the remainder of the record (so smaller 401 than 65535 octets and constrained by the RDATA and DNS message 402 sizes). 404 When the list of SvcParams is non-empty, it contains a series of 405 SvcParamKey=SvcParamValue pairs, represented as: 407 * a 2-octet field containing the SvcParamKey as an integer in 408 network byte order. (See Section 15.3.2 for the defined values.) 410 * a 2-octet field containing the length of the SvcParamValue as an 411 integer between 0 and 65535 in network byte order. 413 * an octet string of this length whose contents are the 414 SvcParamValue in a format determined by the SvcParamKey. 416 SvcParamKeys SHALL appear in increasing numeric order. 418 Clients MUST consider an RR malformed if: 420 * the end of the RDATA occurs within a SvcParam. 422 * SvcParamKeys are not in strictly increasing numeric order. 424 * the SvcParamValue for an SvcParamKey does not have the expected 425 format. 427 Note that the second condition implies that there are no duplicate 428 SvcParamKeys. 430 If any RRs are malformed, the client MUST reject the entire RRSet and 431 fall back to non-SVCB connection establishment. 433 2.3. SVCB query names 435 When querying the SVCB RR, a service is translated into a QNAME by 436 prepending the service name with a label indicating the scheme, 437 prefixed with an underscore, resulting in a domain name like 438 "_examplescheme.api.example.com.". This follows the Attrleaf naming 439 pattern [Attrleaf], so the scheme MUST be registered appropriately 440 with IANA (see Section 12). 442 Protocol mapping documents MAY specify additional underscore-prefixed 443 labels to be prepended. For schemes that specify a port 444 (Section 3.2.3 of [URI]), one reasonable possibility is to prepend 445 the indicated port number if a non-default port number is specified. 446 We term this behavior "Port Prefix Naming", and use it in the 447 examples throughout this document. 449 See Section 9.1 for the HTTPS RR behavior. 451 When a prior CNAME or SVCB record has aliased to a SVCB record, each 452 RR SHALL be returned under its own owner name, as in ordinary CNAME 453 processing ([RFC1034], Section 3.6.2). For details, see the 454 recommendations regarding aliases for clients (Section 3), servers 455 (Section 4), and zones (Section 11). 457 Note that none of these forms alter the origin or authority for 458 validation purposes. For example, TLS clients MUST continue to 459 validate TLS certificates for the original service name. 461 As an example, the owner of example.com could publish this record: 463 _8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net. 465 to indicate that "foo://api.example.com:8443" is aliased to 466 "svc4.example.net". The owner of example.net, in turn, could publish 467 this record: 469 svc4.example.net. 7200 IN SVCB 3 svc4.example.net. ( 470 alpn="bar" port="8004" ech="..." ) 472 to indicate that these services are served on port number 8004, which 473 supports the protocol "bar" and its associated transport in addition 474 to the default transport protocol for "foo://". 476 (Parentheses are used to ignore a line break in DNS zone file 477 presentation format ([RFC1035], Section 5.1).) 479 2.4. Interpretation 481 2.4.1. SvcPriority 483 When SvcPriority is 0 the SVCB record is in AliasMode 484 (Section 2.4.2). Otherwise, it is in ServiceMode (Section 2.4.3). 486 Within a SVCB RRSet, all RRs SHOULD have the same Mode. If an RRSet 487 contains a record in AliasMode, the recipient MUST ignore any 488 ServiceMode records in the set. 490 RRSets are explicitly unordered collections, so the SvcPriority field 491 is used to impose an ordering on SVCB RRs. A smaller SvcPriority 492 indicates that the domain owner recommends use of this record over 493 ServiceMode RRs with a larger SvcPriority value. 495 When receiving an RRSet containing multiple SVCB records with the 496 same SvcPriority value, clients SHOULD apply a random shuffle within 497 a priority level to the records before using them, to ensure uniform 498 load-balancing. 500 2.4.2. AliasMode 502 In AliasMode, the SVCB record aliases a service to a TargetName. 503 SVCB RRSets SHOULD only have a single resource record in AliasMode. 504 If multiple are present, clients or recursive resolvers SHOULD pick 505 one at random. 507 The primary purpose of AliasMode is to allow aliasing at the zone 508 apex, where CNAME is not allowed (see e.g. [RFC1912], Section 2.4). 509 In AliasMode, the TargetName will be the name of a domain that 510 resolves to SVCB, AAAA, and/or A records. (See Section 6 for 511 aliasing of SVCB-compatible RR types.) Unlike CNAME, AliasMode 512 records do not affect the resolution of other RR types, and apply 513 only to a specific service, not an entire domain name. 515 The AliasMode TargetName SHOULD NOT be equal to the owner name, as 516 this would result in a loop. In AliasMode, recipients MUST ignore 517 any SvcParams that are present. Zone-file parsers MAY emit a warning 518 if an AliasMode record has SvcParams. The use of SvcParams in 519 AliasMode records is currently not defined, but a future 520 specification could extend AliasMode records to include SvcParams. 522 For example, the operator of foo://example.com:8080 could point 523 requests to a service operating at foosvc.example.net by publishing: 525 _8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net. 527 Using AliasMode maintains a separation of concerns: the owner of 528 foosvc.example.net can add or remove ServiceMode SVCB records without 529 requiring a corresponding change to example.com. Note that if 530 foosvc.example.net promises to always publish a SVCB record, this 531 AliasMode record can be replaced by a CNAME at the same owner name, 532 which would likely improve performance. 534 AliasMode is especially useful for SVCB-compatible RR types that do 535 not require an underscore prefix, such as the HTTPS RR type. For 536 example, the operator of https://example.com could point requests to 537 a server at svc.example.net by publishing this record at the zone 538 apex: 540 example.com. 3600 IN HTTPS 0 svc.example.net. 542 Note that the SVCB record's owner name MAY be the canonical name of a 543 CNAME record, and the TargetName MAY be the owner of a CNAME record. 544 Clients and recursive resolvers MUST follow CNAMEs as normal. 546 To avoid unbounded alias chains, clients and recursive resolvers MUST 547 impose a limit on the total number of SVCB aliases they will follow 548 for each resolution request. This limit MUST NOT be zero, i.e. 549 implementations MUST be able to follow at least one AliasMode record. 550 The exact value of this limit is left to implementations. 552 Zones that require following multiple AliasMode records could 553 encounter compatibility and performance issues. 555 As legacy clients will not know to use this record, service operators 556 will likely need to retain fallback AAAA and A records alongside this 557 SVCB record, although in a common case the target of the SVCB record 558 might offer better performance, and therefore would be preferable for 559 clients implementing this specification to use. 561 AliasMode records only apply to queries for the specific RR type. 562 For example, a SVCB record cannot alias to an HTTPS record, nor vice- 563 versa. 565 2.4.3. ServiceMode 567 In ServiceMode, the TargetName and SvcParams within each resource 568 record associate an alternative endpoint for the service with its 569 connection parameters. 571 Each protocol scheme that uses SVCB MUST define a protocol mapping 572 that explains how SvcParams are applied for connections of that 573 scheme. Unless specified otherwise by the protocol mapping, clients 574 MUST ignore any SvcParam that they do not recognize. 576 Some SvcParams impose requirements on other SvcParams in the RR. A 577 ServiceMode RR is called "self-consistent" if its SvcParams all 578 comply with each other's requirements. Clients MUST reject any RR 579 whose recognized SvcParams are not self-consistent, and MAY reject 580 the entire RRSet. To help zone operators avoid this condition, zone- 581 file implementations SHOULD enforce self-consistency as well. 583 2.5. Special handling of "." in TargetName 585 If TargetName has the value "." (represented in the wire format as a 586 zero-length label), special rules apply. 588 2.5.1. AliasMode 590 For AliasMode SVCB RRs, a TargetName of "." indicates that the 591 service is not available or does not exist. This indication is 592 advisory: clients encountering this indication MAY ignore it and 593 attempt to connect without the use of SVCB. 595 2.5.2. ServiceMode 597 For ServiceMode SVCB RRs, if TargetName has the value ".", then the 598 owner name of this record MUST be used as the effective TargetName. 599 If the record has a wildcard owner name in the zone file, the 600 recipient SHALL use the response's synthesized owner name as the 601 effective TargetName. 603 For example, in the following example "svc2.example.net" is the 604 effective TargetName: 606 example.com. 7200 IN HTTPS 0 svc.example.net. 607 svc.example.net. 7200 IN CNAME svc2.example.net. 608 svc2.example.net. 7200 IN HTTPS 1 . port=8002 ech="..." 609 svc2.example.net. 300 IN A 192.0.2.2 610 svc2.example.net. 300 IN AAAA 2001:db8::2 612 3. Client behavior 614 "SVCB resolution" is the process of enumerating the priority-ordered 615 endpoints for a service, as performed by the client. SVCB resolution 616 is implemented as follows: 618 1. Let $QNAME be the service name plus appropriate prefixes for the 619 scheme (see Section 2.3). 621 2. Issue a SVCB query for $QNAME. 623 3. If an AliasMode SVCB record is returned for $QNAME (after 624 following CNAMEs as normal), set $QNAME to its TargetName 625 (without additional prefixes) and loop back to step 2, subject to 626 chain length limits and loop detection heuristics (see 627 Section 3.1). 629 4. If one or more "compatible" (Section 8) ServiceMode records are 630 returned, these represent the alternative endpoints. 632 5. Otherwise, SVCB resolution has failed, and the list of known 633 endpoints is empty. 635 This procedure does not rely on any recursive or authoritative DNS 636 server to comply with this specification or have any awareness of 637 SVCB. 639 A client is called "SVCB-optional" if it can connect without the use 640 of ServiceMode records, and "SVCB-reliant" otherwise. Clients for 641 pre-existing protocols (e.g. HTTP) SHALL implement SVCB-optional 642 behavior (except as noted in Section 3.1 and Section 10.1). 644 SVCB-optional clients SHOULD issue in parallel any other DNS queries 645 that might be needed for connection establishment if the SVCB record 646 is absent, in order to minimize delay in that case and enable the 647 optimizations discussed in Section 5. 649 Once SVCB resolution has concluded, whether successful or not, SVCB- 650 optional clients SHALL append to the priority list an endpoint 651 consisting of the final value of $QNAME, the authority endpoint's 652 port number, and no SvcParams. (This endpoint will be attempted 653 before falling back to non-SVCB connection modes. This ensures that 654 SVCB-optional clients will make use of an AliasMode record whose 655 TargetName has A and/or AAAA records but no SVCB records.) 657 The client proceeds with connection establishment using the resolved 658 list of endpoints. Clients SHOULD try higher-priority alternatives 659 first, with fallback to lower-priority alternatives. Clients resolve 660 AAAA and/or A records for the selected TargetName, and MAY choose 661 between them using an approach such as Happy Eyeballs 662 [HappyEyeballsV2]. 664 If the client is SVCB-optional, and connecting using this list of 665 endpoints has failed, the client now attempts to use non-SVCB 666 connection modes. 668 Some important optimizations are discussed in Section 5 to avoid 669 additional latency in comparison to ordinary AAAA/A lookups. 671 3.1. Handling resolution failures 673 If DNS responses are cryptographically protected (e.g. using DNSSEC 674 or TLS [DoT][DoH]), and SVCB resolution fails due to an 675 authentication error, SERVFAIL response, transport error, or timeout, 676 the client SHOULD abandon its attempt to reach the service, even if 677 the client is SVCB-optional. Otherwise, an active attacker could 678 mount a downgrade attack by denying the user access to the SvcParams. 680 A SERVFAIL error can occur if the domain is DNSSEC-signed, the 681 recursive resolver is DNSSEC-validating, and the attacker is between 682 the recursive resolver and the authoritative DNS server. A transport 683 error or timeout can occur if an active attacker between the client 684 and the recursive resolver is selectively dropping SVCB queries or 685 responses, based on their size or other observable patterns. 687 If the client enforces DNSSEC validation on A/AAAA responses, it 688 SHOULD apply the same validation policy to SVCB. Otherwise, an 689 attacker could defeat the A/AAAA protection by forging SVCB responses 690 that direct the client to other IP addresses. 692 If DNS responses are not cryptographically protected, clients MAY 693 treat SVCB resolution failure as fatal or nonfatal. 695 If the client is unable to complete SVCB resolution due to its chain 696 length limit, the client MUST fall back to the authority endpoint, as 697 if the origin's SVCB record did not exist. 699 3.2. Clients using a Proxy 701 Clients using a domain-oriented transport proxy like HTTP CONNECT 702 ([RFC7231], Section 4.3.6) or SOCKS5 ([RFC1928]) have the option to 703 use named destinations, in which case the client does not perform any 704 A or AAAA queries for destination domains. If the client is 705 configured to use named destinations with a proxy that does not 706 provide SVCB query capability (e.g. through an affiliated DNS 707 resolver), the client would have to perform SVCB resolution 708 separately, likely disclosing the destinations to additional parties 709 than just the proxy. Clients in this configuration SHOULD arrange 710 for a separate SVCB resolution procedure with appropriate privacy 711 properties. If this is not possible, SVCB-optional clients MUST 712 disable SVCB resolution entirely, and SVCB-required clients MUST 713 treat the configuration as invalid. 715 If the client does use SVCB and named destinations, the client SHOULD 716 follow the standard SVCB resolution process, selecting the smallest- 717 SvcPriority option that is compatible with the client and the proxy. 718 When connecting using a SVCB record, clients MUST provide the final 719 TargetName and port to the proxy, which will perform any required A 720 and AAAA lookups. 722 This arrangement has several benefits: 724 * Compared to disabling SVCB: 726 - It allows the client to use the SvcParams, if present, which 727 are only usable with a specific TargetName. The SvcParams may 728 include information that enhances performance (e.g. alpn) and 729 privacy (e.g. ech). 731 - It allows the service to delegate the apex domain. 733 * Compared to providing the proxy with an IP address: 735 - It allows the proxy to select between IPv4 and IPv6 addresses 736 for the server according to its configuration. 738 - It ensures that the proxy receives addresses based on its 739 network geolocation, not the client's. 741 - It enables faster fallback for TCP destinations with multiple 742 addresses of the same family. 744 4. DNS Server Behavior 746 4.1. Authoritative servers 748 When replying to a SVCB query, authoritative DNS servers SHOULD 749 return A, AAAA, and SVCB records in the Additional Section for any 750 TargetNames that are in the zone. If the zone is signed, the server 751 SHOULD also include positive or negative DNSSEC responses for these 752 records in the Additional section. 754 See Section 4.4 for exceptions. 756 4.2. Recursive resolvers 758 Whether the recursive resolver is aware of SVCB or not, the normal 759 response construction process (i.e. unknown RR type resolution under 760 [RFC3597]) generates the Answer section of the response. Recursive 761 resolvers that are aware of SVCB SHOULD help the client to execute 762 the procedure in Section 3 with minimum overall latency by 763 incorporating additional useful information into the Additional 764 section of the response as follows: 766 1. Incorporate the results of SVCB resolution. If the recursive 767 resolver's local chain length limit (which may be different from 768 the client's limit) has been reached, terminate. 770 2. If any of the resolved SVCB records are in AliasMode, choose one 771 of them at random, and resolve SVCB, A, and AAAA records for its 772 TargetName. 774 * If any SVCB records are resolved, go to step 1. 776 * Otherwise, incorporate the results of A and AAAA resolution, 777 and terminate. 779 3. All the resolved SVCB records are in ServiceMode. Resolve A and 780 AAAA queries for each TargetName (or for the owner name if 781 TargetName is "."), incorporate all the results, and terminate. 783 In this procedure, "resolve" means the resolver's ordinary recursive 784 resolution procedure, as if processing a query for that RRSet. This 785 includes following any aliases that the resolver would ordinarily 786 follow (e.g. CNAME, DNAME [DNAME]). Errors or anomalies in 787 obtaining additional records MAY cause this process to terminate, but 788 MUST NOT themselves cause the resolver to send a failure response. 790 See Section 2.4.2 for additional safeguards for recursive resolvers 791 to implement to mitigate loops. 793 See Section 5.2 for possible optimizations of this procedure. 795 4.2.1. DNS64 797 DNS64 resolvers synthesize responses to AAAA queries for names that 798 only have an A record (Section 5.1.7 of [RFC6147]). SVCB-aware DNS64 799 resolvers SHOULD apply the same synthesis logic when resolving AAAA 800 records for the TargetName for inclusion as Additionals (Step 2 in 801 Section 4.2), and MAY omit the Additional A records. 803 DNS64 resolvers MUST NOT extrapolate the AAAA synthesis logic to the 804 IP hints in the SvcParams (Section 7.4). Modifying the IP hints 805 would break DNSSEC validation for the SVCB record and would not 806 improve performance when the above recommendation is implemented. 808 4.3. General requirements 810 Recursive resolvers MUST be able to convey SVCB records with 811 unrecognized SvcParamKeys, and MAY treat the entire SvcParams portion 812 of the record as opaque, even if the contents are invalid. 813 Alternatively, recursive resolvers MAY report an error such as 814 SERVFAIL to avoid returning a SvcParamValue that is invalid according 815 to the SvcParam's specification. For complex value types whose 816 interpretation might differ between implementations or have 817 additional future allowed values added (e.g. URIs or "alpn"), 818 resolvers SHOULD limit validation to specified constraints. 820 When responding to a query that includes the DNSSEC OK bit 821 ([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers 822 MUST accompany each RRSet in the Additional section with the same 823 DNSSEC-related records that they would send when providing that RRSet 824 as an Answer (e.g. RRSIG, NSEC, NSEC3). 826 According to Section 5.4.1 of [RFC2181], "Unauthenticated RRs 827 received and cached from ... the additional data section ... should 828 not be cached in such a way that they would ever be returned as 829 answers to a received query. They may be returned as additional 830 information where appropriate.". Recursive resolvers therefore MAY 831 cache records from the Additional section for use in populating 832 Additional section responses, and MAY cache them for general use if 833 they are authenticated by DNSSEC. 835 4.4. EDNS Client Subnet (ECS) 837 The EDNS Client Subnet option (ECS, [RFC7871]) allows recursive 838 resolvers to request IP addresses that are suitable for a particular 839 client IP range. SVCB records may contain IP addresses (in ipv*hint 840 SvcParams), or direct users to a subnet-specific TargetName, so 841 recursive resolvers SHOULD include the same ECS option in SVCB 842 queries as in A/AAAA queries. 844 According to Section 7.3.1 of [RFC7871], "Any records from [the 845 Additional section] MUST NOT be tied to a network". Accordingly, 846 when processing a response whose QTYPE is SVCB-compatible, resolvers 847 SHOULD treat any records in the Additional section as having SOURCE 848 PREFIX-LENGTH zero and SCOPE PREFIX-LENGTH as specified in the ECS 849 option. Authoritative servers MUST omit such records if they are not 850 suitable for use by any stub resolvers that set SOURCE PREFIX-LENGTH 851 to zero. This will cause the resolver to perform a follow-up query 852 that can receive properly tailored ECS. (This is similar to the 853 usage of CNAME with ECS discussed in [RFC7871], Section 7.2.1.) 855 Authoritative servers that omit Additional records can avoid the 856 added latency of a follow-up query by following the advice in 857 Section 11.2. 859 5. Performance optimizations 861 For optimal performance (i.e. minimum connection setup time), clients 862 SHOULD implement a client-side DNS cache. Responses in the 863 Additional section of a SVCB response SHOULD be placed in cache 864 before performing any follow-up queries. With this behavior, and 865 conforming DNS servers, using SVCB does not add network latency to 866 connection setup. 868 To improve performance when using a non-conforming recursive 869 resolver, clients SHOULD issue speculative A and/or AAAA queries in 870 parallel with each SVCB query, based on a predicted value of 871 TargetName (see Section 11.2). 873 After a ServiceMode RRSet is received, clients MAY try more than one 874 option in parallel, and MAY prefetch A and AAAA records for multiple 875 TargetNames. 877 5.1. Optimistic pre-connection and connection reuse 879 If an address response arrives before the corresponding SVCB 880 response, the client MAY initiate a connection as if the SVCB query 881 returned NODATA, but MUST NOT transmit any information that could be 882 altered by the SVCB response until it arrives. For example, a TLS 883 ClientHello can be altered by the "ech" value of a SVCB response 884 (Section 7.3). Clients implementing this optimization SHOULD wait 885 for 50 milliseconds before starting optimistic pre-connection, as per 886 the guidance in [HappyEyeballsV2]. 888 A SVCB record is consistent with a connection if the client would 889 attempt an equivalent connection when making use of that record. If 890 a SVCB record is consistent with an active or in-progress connection 891 C, the client MAY prefer that record and use C as its connection. 892 For example, suppose the client receives this SVCB RRSet for a 893 protocol that uses TLS over TCP: 895 _1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. ( 896 ech="111..." ipv6hint=2001:db8::1 port=1234 ) 897 SVCB 2 svc2.example.net. ( 898 ech="222..." ipv6hint=2001:db8::2 port=1234 ) 900 If the client has an in-progress TCP connection to 901 [2001:db8::2]:1234, it MAY proceed with TLS on that connection using 902 ech="222...", even though the other record in the RRSet has higher 903 priority. 905 If none of the SVCB records are consistent with any active or in- 906 progress connection, clients proceed with connection establishment as 907 described in Section 3. 909 5.2. Generating and using incomplete responses 911 When following the procedure in Section 4.2, recursive resolvers MAY 912 terminate the procedure early and produce a reply that omits some of 913 the associated RRSets. This is REQUIRED when the chain length limit 914 is reached (Section 4.2 step 1), but might also be appropriate when 915 the maximum response size is reached, or when responding before fully 916 chasing dependencies would improve performance. When omitting 917 certain RRSets, recursive resolvers SHOULD prioritize information for 918 smaller-SvcPriority records. 920 As discussed in Section 3, clients MUST be able to fetch additional 921 information that is required to use a SVCB record, if it is not 922 included in the initial response. As a performance optimization, if 923 some of the SVCB records in the response can be used without 924 requiring additional DNS queries, the client MAY prefer those 925 records, regardless of their priorities. 927 6. SVCB-compatible 929 An RR type is called "SVCB-compatible" if it permits an 930 implementation that is identical to SVCB in its: 932 * RDATA presentation format 934 * RDATA wire format 936 * IANA registry used for SvcParamKeys 938 * Authoritative server Additional Section processing 940 * Recursive resolution process 942 * Relevant Class (i.e. Internet ("IN") [RFC1035]) 944 This allows authoritative and recursive DNS servers to apply 945 identical processing to all SVCB-compatible RR types. 947 All other behaviors described as applying to the SVCB RR also apply 948 to all SVCB-compatible RR types unless explicitly stated otherwise. 949 When following an AliasMode record (Section 2.4.2) of RR type $T , 950 the followup query to the TargetName MUST also be for type $T. 952 This document defines one SVCB-compatible RR type (other than SVCB 953 itself): the HTTPS RR type (Section 9), which avoids Attrleaf label 954 prefixes [Attrleaf] in order to improve compatibility with wildcards 955 and CNAMEs, which are widely used with HTTP. 957 Standards authors should consider carefully whether to use SVCB or 958 define a new SVCB-compatible RR type, as this choice cannot easily be 959 reversed after deployment. 961 7. Initial SvcParamKeys 963 A few initial SvcParamKeys are defined here. These keys are useful 964 for the "https" scheme, and most are expected to be generally 965 applicable to other schemes as well. 967 Each new protocol mapping document MUST specify which keys are 968 applicable and safe to use. Protocol mappings MAY alter the 969 interpretation of SvcParamKeys but MUST NOT alter their presentation 970 or wire formats. 972 7.1. "alpn" and "no-default-alpn" 974 The "alpn" and "no-default-alpn" SvcParamKeys together indicate the 975 set of Application Layer Protocol Negotiation (ALPN) protocol 976 identifiers [ALPN] and associated transport protocols supported by 977 this service endpoint (the "SVCB ALPN set"). 979 As with Alt-Svc [AltSvc], each ALPN protocol identifier is used to 980 identify the application protocol and associated suite of protocols 981 supported by the endpoint (the "protocol suite"). The presence of an 982 ALPN protocol identifier in the SVCB ALPN set indicates that this 983 service endpoint, described by TargetName and the other parameters 984 (e.g. "port") offers service with the protocol suite associated with 985 this ALPN identifier. 987 Clients filter the set of ALPN identifiers to match the protocol 988 suites they support, and this informs the underlying transport 989 protocol used (such as QUIC-over-UDP or TLS-over-TCP). ALPN protocol 990 identifiers that do not uniquely identify a protocol suite (e.g. an 991 Identification Sequence that can be used with both TLS and DTLS) are 992 not compatible with this SvcParamKey and MUST NOT be included in the 993 SVCB ALPN set. 995 7.1.1. Representation 997 ALPNs are identified by their registered "Identification Sequence" 998 (alpn-id), which is a sequence of 1-255 octets. 1000 alpn-id = 1*255OCTET 1002 For "alpn", the presentation value SHALL be a comma-separated list 1003 (Appendix A.1) of one or more alpn-ids. Zone file implementations 1004 MAY disallow the "," and "\" characters instead of implementing the 1005 value-list escaping procedure, relying on the opaque key format (e.g. 1006 key1=\002h2) in the event that these characters are needed. 1008 The wire format value for "alpn" consists of at least one alpn-id 1009 prefixed by its length as a single octet, and these length-value 1010 pairs are concatenated to form the SvcParamValue. These pairs MUST 1011 exactly fill the SvcParamValue; otherwise, the SvcParamValue is 1012 malformed. 1014 For "no-default-alpn", the presentation and wire format values MUST 1015 be empty. When "no-default-alpn" is specified in an RR, "alpn" must 1016 also be specified in order for the RR to be "self-consistent" 1017 (Section 2.4.3). 1019 Each scheme that uses this SvcParamKey defines a "default set" of 1020 ALPNs that are supported by nearly all clients and servers, which MAY 1021 be empty. To determine the SVCB ALPN set, the client starts with the 1022 list of alpn-ids from the "alpn" SvcParamKey, and adds the default 1023 set unless the "no-default-alpn" SvcParamKey is present. 1025 7.1.2. Use 1027 To establish a connection to the endpoint, clients MUST 1029 1. Let SVCB-ALPN-Intersection be the set of protocols in the SVCB 1030 ALPN set that the client supports. 1032 2. Let Intersection-Transports be the set of transports (e.g. TLS, 1033 DTLS, QUIC) implied by the protocols in SVCB-ALPN-Intersection. 1035 3. For each transport in Intersection-Transports, construct a 1036 ProtocolNameList containing the Identification Sequences of all 1037 the client's supported ALPN protocols for that transport, without 1038 regard to the SVCB ALPN set. 1040 For example, if the SVCB ALPN set is ["http/1.1", "h3"], and the 1041 client supports HTTP/1.1, HTTP/2, and HTTP/3, the client could 1042 attempt to connect using TLS over TCP with a ProtocolNameList of 1043 ["http/1.1", "h2"], and could also attempt a connection using QUIC, 1044 with a ProtocolNameList of ["h3"]. 1046 Once the client has constructed a ClientHello, protocol negotiation 1047 in that handshake proceeds as specified in [ALPN], without regard to 1048 the SVCB ALPN set. 1050 Clients MAY implement a fallback procedure, using a less-preferred 1051 transport if more-preferred transports fail to connect. This 1052 fallback behavior is vulnerable to manipulation by a network attacker 1053 who blocks the more-preferred transports, but it may be necessary for 1054 compatibility with existing networks. 1056 With this procedure in place, an attacker who can modify DNS and 1057 network traffic can prevent a successful transport connection, but 1058 cannot otherwise interfere with ALPN protocol selection. This 1059 procedure also ensures that each ProtocolNameList includes at least 1060 one protocol from the SVCB ALPN set. 1062 Clients SHOULD NOT attempt connection to a service endpoint whose 1063 SVCB ALPN set does not contain any supported protocols. 1065 To ensure consistency of behavior, clients MAY reject the entire SVCB 1066 RRSet and fall back to basic connection establishment if all of the 1067 compatible RRs indicate "no-default-alpn", even if connection could 1068 have succeeded using a non-default alpn. 1070 Zone operators SHOULD ensure that at least one RR in each RRSet 1071 supports the default transports. This enables compatibility with the 1072 greatest number of clients. 1074 7.2. "port" 1076 The "port" SvcParamKey defines the TCP or UDP port that should be 1077 used to reach this alternative endpoint. If this key is not present, 1078 clients SHALL use the authority endpoint's port number. 1080 The presentation value of the SvcParamValue is a single decimal 1081 integer between 0 and 65535 in ASCII. Any other value (e.g. an empty 1082 value) is a syntax error. To enable simpler parsing, this SvcParam 1083 MUST NOT contain escape sequences. 1085 The wire format of the SvcParamValue is the corresponding 2 octet 1086 numeric value in network byte order. 1088 If a port-restricting firewall is in place between some client and 1089 the service endpoint, changing the port number might cause that 1090 client to lose access to the service, so operators should exercise 1091 caution when using this SvcParamKey to specify a non-default port. 1093 7.3. "ech" 1095 The SvcParamKey to enable Encrypted ClientHello (ECH) is "ech". Its 1096 value is defined in Section 10. It is applicable to most TLS-based 1097 protocols. 1099 When publishing a record containing an "ech" parameter, the publisher 1100 MUST ensure that all IP addresses of TargetName correspond to servers 1101 that have access to the corresponding private key or are 1102 authoritative for the public name. (See Section 7.2.2 of [ECH] for 1103 more details about the public name.) This yields an anonymity set of 1104 cardinality equal to the number of ECH-enabled server domains 1105 supported by a given client-facing server. Thus, even with an 1106 encrypted ClientHello, an attacker who can enumerate the set of ECH- 1107 enabled domains supported by a client-facing server can guess the 1108 correct SNI with probability at least 1/K, where K is the size of 1109 this ECH-enabled server anonymity set. This probability may be 1110 increased via traffic analysis or other mechanisms. 1112 7.4. "ipv4hint" and "ipv6hint" 1114 The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients 1115 MAY use to reach the service. If A and AAAA records for TargetName 1116 are locally available, the client SHOULD ignore these hints. 1117 Otherwise, clients SHOULD perform A and/or AAAA queries for 1118 TargetName as in Section 3, and clients SHOULD use the IP address in 1119 those responses for future connections. Clients MAY opt to terminate 1120 any connections using the addresses in hints and instead switch to 1121 the addresses in response to the TargetName query. Failure to use A 1122 and/or AAAA response addresses could negatively impact load balancing 1123 or other geo-aware features and thereby degrade client performance. 1125 The presentation value SHALL be a comma-separated list (Appendix A.1) 1126 of one or more IP addresses of the appropriate family in standard 1127 textual format [RFC5952][RFC4001]. To enable simpler parsing, this 1128 SvcParamValue MUST NOT contain escape sequences. 1130 The wire format for each parameter is a sequence of IP addresses in 1131 network byte order (for the respective address-family). Like an A or 1132 AAAA RRSet, the list of addresses represents an unordered collection, 1133 and clients SHOULD pick addresses to use in a random order. An empty 1134 list of addresses is invalid. 1136 When selecting between IPv4 and IPv6 addresses to use, clients may 1137 use an approach such as Happy Eyeballs [HappyEyeballsV2]. When only 1138 "ipv4hint" is present, NAT64 clients may synthesize IPv6 addresses as 1139 specified in [RFC7050] or ignore the "ipv4hint" key and wait for AAAA 1140 resolution (Section 3). For best performance, server operators 1141 SHOULD include an "ipv6hint" parameter whenever they include an 1142 "ipv4hint" parameter. 1144 These parameters are intended to minimize additional connection 1145 latency when a recursive resolver is not compliant with the 1146 requirements in Section 4, and SHOULD NOT be included if most clients 1147 are using compliant recursive resolvers. When TargetName is the 1148 origin hostname or the owner name (which can be written as "."), 1149 server operators SHOULD NOT include these hints, because they are 1150 unlikely to convey any performance benefit. 1152 7.5. "mandatory" 1154 See Section 8. 1156 8. ServiceMode RR compatibility and mandatory keys 1158 In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the 1159 RR will not function correctly for clients that ignore this 1160 SvcParamKey. Each SVCB protocol mapping SHOULD specify a set of keys 1161 that are "automatically mandatory", i.e. mandatory if they are 1162 present in an RR. The SvcParamKey "mandatory" is used to indicate 1163 any mandatory keys for this RR, in addition to any automatically 1164 mandatory keys that are present. 1166 A ServiceMode RR is considered "compatible" by a client if the client 1167 recognizes all the mandatory keys, and their values indicate that 1168 successful connection establishment is possible. If the SVCB RRSet 1169 contains no compatible RRs, the client will generally act as if the 1170 RRSet is empty. 1172 The presentation value SHALL be a comma-separated list (Appendix A.1) 1173 of one or more valid SvcParamKeys, either by their registered name or 1174 in the unknown-key format (Section 2.1). Keys MAY appear in any 1175 order, but MUST NOT appear more than once. For self-consistency 1176 (Section 2.4.3), listed keys MUST also appear in the SvcParams. 1178 To enable simpler parsing, this SvcParamValue MUST NOT contain escape 1179 sequences. 1181 For example, the following is a valid list of SvcParams: 1183 ech=... key65333=ex1 key65444=ex2 mandatory=key65444,ech 1185 In wire format, the keys are represented by their numeric values in 1186 network byte order, concatenated in strictly increasing numeric 1187 order. 1189 This SvcParamKey is always automatically mandatory, and MUST NOT 1190 appear in its own value-list. Other automatically mandatory keys 1191 SHOULD NOT appear in the list either. (Including them wastes space 1192 and otherwise has no effect.) 1194 9. Using Service Bindings with HTTP 1196 Use of any protocol with SVCB requires a protocol-specific mapping 1197 specification. This section specifies the mapping for the "http" and 1198 "https" URI schemes [HTTP]. 1200 To enable special handling for HTTP use-cases, the HTTPS RR type is 1201 defined as a SVCB-compatible RR type, specific to the "https" and 1202 "http" schemes. Clients MUST NOT perform SVCB queries or accept SVCB 1203 responses for "https" or "http" schemes. 1205 The presentation format of the record is: 1207 Name TTL IN HTTPS SvcPriority TargetName SvcParams 1209 All the SvcParamKeys defined in Section 7 are permitted for use in 1210 HTTPS RRs. The default set of ALPN IDs is the single value 1211 "http/1.1". The "automatically mandatory" keys (Section 8) are 1212 "port" and "no-default-alpn". (As described in Section 8, clients 1213 must either implement these keys or ignore any RR in which they 1214 appear.) Clients that restrict the destination port in "https" URIs 1215 (e.g. using the "bad ports" list from [FETCH]) SHOULD apply the same 1216 restriction to the "port" SvcParam. 1218 The presence of an HTTPS RR for an origin also indicates that clients 1219 should connect securely and use the "https" scheme, as discussed in 1220 Section 9.5. This allows HTTPS RRs to apply to pre-existing "http" 1221 scheme URLs, while ensuring that the client uses a secure and 1222 authenticated connection. 1224 The HTTPS RR parallels the concepts introduced in the HTTP 1225 Alternative Services proposed standard [AltSvc]. Clients and servers 1226 that implement HTTPS RRs are not required to implement Alt-Svc. 1228 9.1. Query names for HTTPS RRs 1230 The HTTPS RR uses Port Prefix Naming (Section 2.3), with one 1231 modification: if the scheme is "https" and the port is 443, then the 1232 client's original QNAME is equal to the service name (i.e. the 1233 origin's hostname), without any prefix labels. 1235 By removing the Attrleaf labels [Attrleaf] used in SVCB, this 1236 construction enables offline DNSSEC signing of wildcard domains, 1237 which are commonly used with HTTP. Using the service name as the 1238 owner name of the HTTPS record, without prefixes, also allows the 1239 targets of existing CNAME chains (e.g. CDN hosts) to start returning 1240 HTTPS RR responses without requiring origin domains to configure and 1241 maintain an additional delegation. 1243 Following of HTTPS AliasMode RRs and CNAME aliases is unchanged from 1244 SVCB. 1246 Clients always convert "http" URLs to "https" before performing an 1247 HTTPS RR query using the process described in Section 9.5, so domain 1248 owners MUST NOT publish HTTPS RRs with a prefix of "_http". 1250 Note that none of these forms alter the HTTPS origin or authority. 1251 For example, clients MUST continue to validate TLS certificate 1252 hostnames based on the origin. 1254 9.2. Comparison with Alt-Svc 1256 Publishing a ServiceMode HTTPS RR in DNS is intended to be similar to 1257 transmitting an Alt-Svc field value over HTTP, and receiving an HTTPS 1258 RR is intended to be similar to receiving that field value over HTTP. 1259 However, there are some differences in the intended client and server 1260 behavior. 1262 9.2.1. ALPN usage 1264 Unlike Alt-Svc Field Values, HTTPS RRs can contain multiple ALPN IDs. 1265 The meaning and use of these IDs is discussed in Section 7.1.2. 1267 9.2.2. Untrusted channel 1269 HTTPS records do not require or provide any assurance of 1270 authenticity. (DNSSEC signing and verification, which would provide 1271 such assurance, are OPTIONAL.) The DNS resolution process is modeled 1272 as an untrusted channel that might be controlled by an attacker, so 1273 Alt-Svc parameters that cannot be safely received in this model MUST 1274 NOT have a corresponding defined SvcParamKey. For example, there is 1275 no SvcParamKey corresponding to the Alt-Svc "persist" parameter, 1276 because this parameter is not safe to accept over an untrusted 1277 channel. 1279 9.2.3. Cache lifetime 1281 There is no SvcParamKey corresponding to the Alt-Svc "ma" (max age) 1282 parameter. Instead, server operators encode the expiration time in 1283 the DNS TTL. 1285 The appropriate TTL value might be different from the "ma" value used 1286 for Alt-Svc, depending on the desired efficiency and agility. Some 1287 DNS caches incorrectly extend the lifetime of DNS records beyond the 1288 stated TTL, so server operators cannot rely on HTTPS RRs expiring on 1289 time. Shortening the TTL to compensate for incorrect caching is NOT 1290 RECOMMENDED, as this practice impairs the performance of correctly 1291 functioning caches and does not guarantee faster expiration from 1292 incorrect caches. Instead, server operators SHOULD maintain 1293 compatibility with expired records until they observe that nearly all 1294 connections have migrated to the new configuration. 1296 9.2.4. Granularity 1298 Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc 1299 Field Value specifically to the client. When using an HTTPS RR, 1300 groups of clients will necessarily receive the same SvcParams. 1301 Therefore, HTTPS RRs are not suitable for uses that require single- 1302 client granularity. 1304 9.3. Interaction with Alt-Svc 1306 Clients that implement support for both Alt-Svc and HTTPS records and 1307 are making a connection based on a cached Alt-Svc response SHOULD 1308 retrieve any HTTPS records for the Alt-Svc alt-authority, and ensure 1309 that their connection attempts are consistent with both the Alt-Svc 1310 parameters and any received HTTPS SvcParams. If present, the HTTPS 1311 record's TargetName and port are used for connection establishment 1312 (as in Section 3). For example, suppose that "https://example.com" 1313 sends an Alt-Svc field value of: 1315 Alt-Svc: h2="alt.example:443", h2="alt2.example:443", h3=":8443" 1317 The client would retrieve the following HTTPS records: 1319 alt.example. IN HTTPS 1 . alpn=h2,h3 ech=... 1320 alt2.example. IN HTTPS 1 alt2b.example. alpn=h3 ech=... 1321 _8443._https.example.com. IN HTTPS 1 alt3.example. ( 1322 port=9443 alpn=h2,h3 ech=... ) 1324 Based on these inputs, the following connection attempts would always 1325 be allowed: 1327 * HTTP/2 to alt.example:443 1329 * HTTP/3 to alt3.example:9443 1331 * Fallback to the client's non-Alt-Svc connection behavior 1333 ECH-capable clients would use ECH when establishing any of these 1334 connections. 1336 The following connection attempts would not be allowed: 1338 * HTTP/3 to alt.example:443 (not consistent with Alt-Svc) 1339 * Any connection to alt2b.example (no ALPN consistent with both the 1340 HTTPS record and Alt-Svc) 1342 * HTTPS over TCP to any port on alt3.example (not consistent with 1343 Alt-Svc) 1345 The following Alt-Svc-only connection attempts would be allowed only 1346 if the client does not support ECH, as they rely on SVCB-optional 1347 fallback behavior that the client will disable if it implements 1348 support for ECH and the "ech" SvcParam is present (Section 10.1): 1350 * HTTP/2 to alt2.example:443 1352 * HTTP/3 to example.com:8443 1354 Origins that publish an "ech" SvcParam in their HTTPS record SHOULD 1355 also publish an HTTPS record with the "ech" SvcParam for every alt- 1356 authority offered in its Alt-Svc Field Values. Otherwise, clients 1357 might reveal the name of the server in an unencrypted ClientHello. 1358 Similar consistency considerations could apply to future 1359 SvcParamKeys, so alt-authorities SHOULD carry the same SvcParams as 1360 the origin unless a deviation is specifically known to be safe. 1362 As noted in Section 2.4 of [AltSvc], clients MAY disallow any Alt-Svc 1363 connection according to their own criteria, e.g. disallowing Alt-Svc 1364 connections that lack ECH support when there is an active ECH- 1365 protected connection for this origin. 1367 9.4. Requiring Server Name Indication 1369 Clients MUST NOT use an HTTPS RR response unless the client supports 1370 TLS Server Name Indication (SNI) and indicates the origin name in the 1371 TLS ClientHello (which might be encrypted). This supports the 1372 conservation of IP addresses. 1374 Note that the TLS SNI (and also the HTTP "Host" or ":authority") will 1375 indicate the origin, not the TargetName. 1377 9.5. HTTP Strict Transport Security 1379 An HTTPS RR directs the client to communicate with this host only 1380 over a secure transport, similar to HTTP Strict Transport Security 1381 [HSTS]. Prior to making an "http" scheme request, the client SHOULD 1382 perform a lookup to determine if any HTTPS RRs exist for that origin. 1383 To do so, the client SHOULD construct a corresponding "https" URL as 1384 follows: 1386 1. Replace the "http" scheme with "https". 1388 2. If the "http" URL explicitly specifies port 80, specify port 443. 1390 3. Do not alter any other aspect of the URL. 1392 This construction is equivalent to Section 8.3 of [HSTS], point 5. 1394 If an HTTPS RR query for this "https" URL returns any AliasMode HTTPS 1395 RRs, or any compatible ServiceMode HTTPS RRs (see Section 8), the 1396 client SHOULD behave as if it has received an HTTP 307 (Temporary 1397 Redirect) status code with this "https" URL in the "Location" field. 1398 (Receipt of an incompatible ServiceMode RR does not trigger the 1399 redirect behavior.) Because HTTPS RRs are received over an often- 1400 insecure channel (DNS), clients MUST NOT place any more trust in this 1401 signal than if they had received a 307 (Temporary Redirect) response 1402 over cleartext HTTP. 1404 Publishing an HTTPS RR has the potential to have unexpected results 1405 or a loss in functionality in cases where the "http" resource neither 1406 redirects to the "https" resource nor references the same underlying 1407 resource. 1409 When an "https" connection fails due to an error in the underlying 1410 secure transport, such as an error in certificate validation, some 1411 clients currently offer a "user recourse" that allows the user to 1412 bypass the security error and connect anyway. When making an "https" 1413 scheme request to an origin with an HTTPS RR, either directly or via 1414 the above redirect, such a client MAY remove the user recourse 1415 option. Origins that publish HTTPS RRs therefore MUST NOT rely on 1416 user recourse for access. For more information, see Section 8.4 and 1417 Section 12.1 of [HSTS]. 1419 9.6. Use of HTTPS RRs in other protocols 1421 All HTTP connections to named origins are eligible to use HTTPS RRs, 1422 even when HTTP is used as part of another protocol or without an 1423 explicit HTTP URL. For example, clients that support HTTPS RRs and 1424 implement the altered WebSocket [WebSocket] opening handshake from 1425 the W3C Fetch specification [FETCH] SHOULD use HTTPS RRs for the 1426 requestURL. 1428 When HTTP is used in a context where URLs or redirects are not 1429 applicable (e.g. connections to an HTTP proxy), clients that find a 1430 corresponding HTTPS RR SHOULD implement a security upgrade behavior 1431 equivalent to the one specified in Section 9.5. 1433 Such protocols MAY define their own SVCB mappings, which MAY be 1434 defined to take precedence over HTTPS RRs. 1436 10. SVCB/HTTPS RR parameter for ECH configuration 1438 The SVCB "ech" parameter is defined for conveying the ECH 1439 configuration of an alternative endpoint. In wire format, the value 1440 of the parameter is an ECHConfigList (Section 4 of [ECH]), including 1441 the redundant length prefix. In presentation format, the value is 1442 the ECHConfigList in Base 64 Encoding (Section 4 of [RFC4648]). Base 1443 64 is used here to simplify integration with TLS server software. To 1444 enable simpler parsing, this SvcParam MUST NOT contain escape 1445 sequences. 1447 When ECH is in use, the TLS ClientHello is divided into an 1448 unencrypted "outer" and an encrypted "inner" ClientHello. The outer 1449 ClientHello is an implementation detail of ECH, and its contents are 1450 controlled by the ECHConfig in accordance with [ECH]. The inner 1451 ClientHello is used for establishing a connection to the service, so 1452 its contents may be influenced by other SVCB parameters. For 1453 example, the requirements on the ALPN protocol identifiers in 1454 Section 7.1 apply only to the inner ClientHello. Similarly, it is 1455 the inner ClientHello whose Server Name Indication identifies the 1456 desired service. 1458 10.1. Client behavior 1460 The SVCB-optional client behavior specified in Section 3 permits 1461 clients to fall back to a direct connection if all SVCB options fail. 1462 This behavior is not suitable for ECH, because fallback would negate 1463 the privacy benefits of ECH. Accordingly, ECH-capable SVCB-optional 1464 clients MUST switch to SVCB-reliant connection establishment if SVCB 1465 resolution succeeded (following Section 3) and all alternative 1466 endpoints have an "ech" key. 1468 As a latency optimization, clients MAY prefetch DNS records that will 1469 only be used in SVCB-optional mode. 1471 10.2. Deployment considerations 1473 An HTTPS RRSet containing some RRs with "ech" and some without is 1474 vulnerable to a downgrade attack. This configuration is NOT 1475 RECOMMENDED. Zone owners who do use such a mixed configuration 1476 SHOULD mark the RRs with "ech" as more preferred (i.e. lower 1477 SvcPriority value) than those without, in order to maximize the 1478 likelihood that ECH will be used in the absence of an active 1479 adversary. 1481 11. Zone Structures 1483 11.1. Structuring zones for flexibility 1485 Each ServiceMode RRSet can only serve a single scheme. The scheme is 1486 indicated by the owner name and the RR type. For the generic SVCB RR 1487 type, this means that each owner name can only be used for a single 1488 scheme. The underscore prefixing requirement (Section 2.3) ensures 1489 that this is true for the initial query, but it is the responsibility 1490 of zone owners to choose names that satisfy this constraint when 1491 using aliases, including CNAME and AliasMode records. 1493 When using the generic SVCB RR type with aliasing, zone owners SHOULD 1494 choose alias target names that indicate the scheme in use (e.g. 1495 foosvc.example.net for foo:// schemes). This will help to avoid 1496 confusion when another scheme needs to be added to the configuration. 1497 When multiple port numbers are in use, it may be helpful to repeat 1498 the prefix labels in the alias target name (e.g. 1499 _1234._foo.svc.example.net). 1501 11.2. Structuring zones for performance 1503 To avoid a delay for clients using a nonconforming recursive 1504 resolver, domain owners SHOULD minimize the use of AliasMode records, 1505 and SHOULD choose TargetName according to a predictable convention 1506 that is known to the client, so that clients can issue A and/or AAAA 1507 queries for TargetName in advance (see Section 5). Unless otherwise 1508 specified, the convention is to set TargetName to the service name 1509 for an initial ServiceMode record, or to "." if it is reached via an 1510 alias. 1512 $ORIGIN example.com. ; Origin 1513 foo 3600 IN CNAME foosvc.example.net. 1514 _8080._foo.foo 3600 IN CNAME foosvc.example.net. 1515 bar 300 IN AAAA 2001:db8::2 1516 _9090._bar.bar 3600 IN SVCB 1 bar key65444=... 1518 $ORIGIN example.net. ; Service provider zone 1519 foosvc 3600 IN SVCB 1 . key65333=... 1520 foosvc 300 IN AAAA 2001:db8::1 1522 Figure 1: foo://foo.example.com:8080 is delegated to 1523 foosvc.example.net, but bar://bar.example.com:9090 is served 1524 locally. 1526 Domain owners SHOULD avoid using a TargetName that is below a DNAME, 1527 as this is likely unnecessary and makes responses slower and larger. 1528 Also, zone structures that require following more than 8 aliases 1529 (counting both AliasMode and CNAME records) are NOT RECOMMENDED. 1531 11.3. Examples 1533 11.3.1. Protocol enhancements 1535 Consider a simple zone of the form: 1537 $ORIGIN simple.example. ; Simple example zone 1538 @ 300 IN A 192.0.2.1 1539 AAAA 2001:db8::1 1541 The domain owner could add this record: 1543 @ 7200 IN HTTPS 1 . alpn=h3 1545 to indicate that https://simple.example supports QUIC in addition to 1546 HTTP/1.1 over TLS over TCP (the implicit default). The record could 1547 also include other information (e.g. non-standard port, ECH 1548 configuration). For https://simple.example:8443, the record would 1549 be: 1551 _8443._https 7200 IN HTTPS 1 . alpn=h3 1553 These records also respectively tell clients to replace the scheme 1554 with "https" when loading http://simple.example or 1555 http://simple.example:8443. 1557 11.3.2. Apex aliasing 1559 Consider a zone that is using CNAME aliasing: 1561 $ORIGIN aliased.example. ; A zone that is using a hosting service 1562 ; Subdomain aliased to a high-performance server pool 1563 www 7200 IN CNAME pool.svc.example. 1564 ; Apex domain on fixed IPs because CNAME is not allowed at the apex 1565 @ 300 IN A 192.0.2.1 1566 IN AAAA 2001:db8::1 1568 With HTTPS RRs, the owner of aliased.example could alias the apex by 1569 adding one additional record: 1571 @ 7200 IN HTTPS 0 pool.svc.example. 1573 With this record in place, HTTPS-RR-aware clients will use the same 1574 server pool for aliased.example and www.aliased.example. (They will 1575 also upgrade "http://aliased.example/..." to "https".) Non-HTTPS-RR- 1576 aware clients will just ignore the new record. 1578 Similar to CNAME, HTTPS RRs have no impact on the origin name. When 1579 connecting, clients will continue to treat the authoritative origins 1580 as "https://www.aliased.example" and "https://aliased.example", 1581 respectively, and will validate TLS server certificates accordingly. 1583 11.3.3. Parameter binding 1585 Suppose that svc.example's primary server pool supports HTTP/3, but 1586 its backup server pool does not. This can be expressed in the 1587 following form: 1589 $ORIGIN svc.example. ; A hosting provider. 1590 pool 7200 IN HTTPS 1 . alpn=h2,h3 ech="123..." 1591 HTTPS 2 backup alpn=h2 ech="abc..." 1592 pool 300 IN A 192.0.2.2 1593 AAAA 2001:db8::2 1594 backup 300 IN A 192.0.2.3 1595 AAAA 2001:db8::3 1597 This configuration is entirely compatible with the "Apex aliasing" 1598 example, whether the client supports HTTPS RRs or not. If the client 1599 does support HTTPS RRs, all connections will be upgraded to HTTPS, 1600 and clients will use HTTP/3 if they can. Parameters are "bound" to 1601 each server pool, so each server pool can have its own protocol, ECH 1602 configuration, etc. 1604 11.3.4. Multi-CDN 1606 The HTTPS RR is intended to support HTTPS services operated by 1607 multiple independent entities, such as different Content Delivery 1608 Networks (CDNs) or different hosting providers. This includes the 1609 case where a service is migrated from one operator to another, as 1610 well as the case where the service is multiplexed between multiple 1611 operators for performance, redundancy, etc. 1613 This example shows such a configuration, with www.customer.example 1614 having different DNS responses to different queries, either over time 1615 or due to logic within the authoritative DNS server: 1617 ; This zone contains/returns different CNAME records 1618 ; at different points-in-time. The RRset for "www" can 1619 ; only ever contain a single CNAME. 1621 ; Sometimes the zone has: 1622 $ORIGIN customer.example. ; A Multi-CDN customer domain 1623 www 900 IN CNAME cdn1.svc1.example. 1625 ; and other times it contains: 1626 $ORIGIN customer.example. 1627 www 900 IN CNAME customer.svc2.example. 1629 ; and yet other times it contains: 1630 $ORIGIN customer.example. 1631 www 900 IN CNAME cdn3.svc3.example. 1633 ; With the following remaining constant and always included: 1634 $ORIGIN customer.example. ; A Multi-CDN customer domain 1635 ; The apex is also aliased to www to match its configuration 1636 @ 7200 IN HTTPS 0 www 1637 ; Non-HTTPS-aware clients use non-CDN IPs 1638 A 203.0.113.82 1639 AAAA 2001:db8:203::2 1641 ; Resolutions following the cdn1.svc1.example 1642 ; path use these records. 1643 ; This CDN uses a different alternative service for HTTP/3. 1644 $ORIGIN svc1.example. ; domain for CDN 1 1645 cdn1 1800 IN HTTPS 1 h3pool alpn=h3 ech="123..." 1646 HTTPS 2 . alpn=h2 ech="123..." 1647 A 192.0.2.2 1648 AAAA 2001:db8:192::4 1649 h3pool 300 IN A 192.0.2.3 1650 AAAA 2001:db8:192:7::3 1652 ; Resolutions following the customer.svc2.example 1653 ; path use these records. 1654 ; Note that this CDN only supports HTTP/2. 1655 $ORIGIN svc2.example. ; domain operated by CDN 2 1656 customer 300 IN HTTPS 1 . alpn=h2 ech="xyz..." 1657 60 IN A 198.51.100.2 1658 A 198.51.100.3 1659 A 198.51.100.4 1660 AAAA 2001:db8:198::7 1661 AAAA 2001:db8:198::12 1663 ; Resolutions following the cdn3.svc3.example 1664 ; path use these records. 1666 ; Note that this CDN has no HTTPS records 1667 ; and thus no ECH support. 1668 $ORIGIN svc3.example. ; domain operated by CDN 3 1669 cdn3 60 IN A 203.0.113.8 1670 AAAA 2001:db8:113::8 1672 Note that in the above example, the different CDNs have different ECH 1673 configurations and different capabilities, but clients will use HTTPS 1674 RRs as a bound-together unit. 1676 Domain owners should be cautious when using a multi-CDN 1677 configuration, as it introduces a number of complexities highlighted 1678 by this example: 1680 * If CDN 1 supports ECH, and CDN 2 does not, the client is 1681 vulnerable to ECH downgrade by a network adversary who forces 1682 clients to get CDN 2 records. 1684 * Aliasing the apex to its subdomain simplifies the zone file but 1685 likely increases resolution latency, especially when using a non- 1686 HTTPS-aware recursive resolver. An alternative would be to alias 1687 the zone apex directly to a name managed by a CDN. 1689 * The A, AAAA, and HTTPS resolutions are independent lookups, so 1690 resolvers may observe and follow different CNAMEs to different 1691 CDNs. Clients may thus find that the A and AAAA responses do not 1692 correspond to the TargetName in the HTTPS response, and will need 1693 to perform additional queries to retrieve the correct IP 1694 addresses. Including ipv6hint and ipv4hint will reduce the 1695 performance impact of this case. 1697 * If not all CDNs publish HTTPS records, clients will sometimes 1698 receive NODATA for HTTPS queries (as with cdn3.svc3.example 1699 above), and thus no "ech" SvcParam, but could receive A/AAAA 1700 records from a different CDN which does support ECH. Clients will 1701 be unable to use ECH in this case. 1703 11.3.5. Non-HTTP uses 1705 For protocols other than HTTP, the SVCB RR and an Attrleaf label 1706 [Attrleaf] will be used. For example, to reach an example resource 1707 of "baz://api.example.com:8765", the following SVCB record would be 1708 used to alias it to "svc4-baz.example.net." which in-turn could 1709 return AAAA/A records and/or SVCB records in ServiceMode: 1711 _8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net. 1713 HTTPS RRs use similar Attrleaf labels if the origin contains a non- 1714 default port. 1716 12. Interaction with other standards 1718 This standard is intended to reduce connection latency and improve 1719 user privacy. Server operators implementing this standard SHOULD 1720 also implement TLS 1.3 [RFC8446] and OCSP Stapling [RFC6066], both of 1721 which confer substantial performance and privacy benefits when used 1722 in combination with SVCB records. 1724 To realize the greatest privacy benefits, this proposal is intended 1725 for use over a privacy-preserving DNS transport (like DNS over TLS 1726 [DoT] or DNS over HTTPS [DoH]). However, performance improvements, 1727 and some modest privacy improvements, are possible without the use of 1728 those standards. 1730 Any specification for use of SVCB with a protocol MUST have an entry 1731 for its scheme under the SVCB RR type in the IANA DNS Underscore 1732 Global Scoped Entry Registry [Attrleaf]. The scheme MUST have an 1733 entry in the IANA URI Schemes Registry [RFC7595], and MUST have a 1734 defined specification for use with SVCB. 1736 13. Security Considerations 1738 SVCB/HTTPS RRs permit distribution over untrusted channels, and 1739 clients are REQUIRED to verify that the alternative endpoint is 1740 authoritative for the service (similar to Section 2.1 of [AltSvc]). 1741 Therefore, DNSSEC signing and validation are OPTIONAL for publishing 1742 and using SVCB and HTTPS RRs. 1744 Clients MUST ensure that their DNS cache is partitioned for each 1745 local network, or flushed on network changes, to prevent a local 1746 adversary in one network from implanting a forged DNS record that 1747 allows them to track users or hinder their connections after they 1748 leave that network. 1750 An attacker who can prevent SVCB resolution can deny clients any 1751 associated security benefits. A hostile recursive resolver can 1752 always deny service to SVCB queries, but network intermediaries can 1753 often prevent resolution as well, even when the client and recursive 1754 resolver validate DNSSEC and use a secure transport. These downgrade 1755 attacks can prevent the "https" upgrade provided by the HTTPS RR 1756 (Section 9.5), and disable the encryption enabled by the "ech" 1757 SvcParamKey (Section 10). To prevent downgrades, Section 3.1 1758 recommends that clients abandon the connection attempt when such an 1759 attack is detected. 1761 A hostile DNS intermediary might forge AliasMode "." records 1762 (Section 2.5.1) as a way to block clients from accessing particular 1763 services. Such an adversary could already block entire domains by 1764 forging erroneous responses, but this mechanism allows them to target 1765 particular protocols or ports within a domain. Clients that might be 1766 subject to such attacks SHOULD ignore AliasMode "." records. 1768 A hostile DNS intermediary or origin can return SVCB records 1769 indicating any IP address and port number, including IP addresses 1770 inside the local network and port numbers assigned to internal 1771 services. If the attacker can influence the client's payload (e.g. 1772 TLS session ticket contents), and an internal service has a 1773 sufficiently lax parser, it's possible that the attacker could gain 1774 unintended access. (The same concerns apply to SRV records, HTTP 1775 Alt-Svc, and HTTP redirects.) As a mitigation, SVCB mapping 1776 documents SHOULD indicate any port number restrictions that are 1777 appropriate for the supported transports. 1779 14. Privacy Considerations 1781 Standard address queries reveal the user's intent to access a 1782 particular domain. This information is visible to the recursive 1783 resolver, and to many other parties when plaintext DNS transport is 1784 used. SVCB queries, like queries for SRV records and other specific 1785 RR types, additionally reveal the user's intent to use a particular 1786 protocol. This is not normally sensitive information, but it should 1787 be considered when adding SVCB support in a new context. 1789 15. IANA Considerations 1791 15.1. SVCB RRType 1793 This document defines a new DNS RR type, SVCB, whose value 64 has 1794 been allocated by IANA from the "Resource Record (RR) TYPEs" registry 1795 on the "Domain Name System (DNS) Parameters" page: 1797 * Type: SVCB 1799 * Value: 64 1801 * Meaning: General Purpose Service Binding 1803 * Reference: This document 1805 15.2. HTTPS RRType 1807 This document defines a new DNS RR type, "HTTPS", whose value 65 has 1808 been allocated by IANA from the "Resource Record (RR) TYPEs" registry 1809 on the "Domain Name System (DNS) Parameters" page: 1811 * Type: HTTPS 1813 * Value: 65 1815 * Meaning: Service Binding type for use with HTTP 1817 * Reference: This document 1819 15.3. New registry for Service Parameters 1821 IANA is requested to create a new registry, entitled "Service 1822 Parameter Keys (SvcParamKeys)". This registry defines the namespace 1823 for parameters, including string representations and numeric 1824 SvcParamKey values. This registry is shared with other SVCB- 1825 compatible RR types, such as the HTTPS RR. 1827 ACTION: create this registry, on a new page entitled "DNS Service 1828 Bindings (SVCB)" under the "Domain Name System (DNS) Parameters" 1829 category. 1831 15.3.1. Procedure 1833 A registration MUST include the following fields: 1835 * Number: wire format numeric identifier (range 0-65535) 1837 * Name: unique presentation name 1839 * Meaning: a short description 1841 * Format Reference: pointer to specification text 1843 * Change Controller: Person or entity, with contact information if 1844 appropriate. 1846 The characters in the registered Name MUST be lower-case alphanumeric 1847 or "-" (Section 2.1). The name MUST NOT start with "key" or 1848 "invalid". 1850 New entries in this registry are subject to an Expert Review 1851 registration policy ([RFC8126], Section 4.5). The designated expert 1852 MUST ensure that the Format Reference is stable and publicly 1853 available, and that it specifies how to convert the SvcParamValue's 1854 presentation format to wire format. The Format Reference MAY be any 1855 individual's Internet-Draft, or a document from any other source with 1856 similar assurances of stability and availability. An entry MAY 1857 specify a Format Reference of the form "Same as (other key Name)" if 1858 it uses the same presentation and wire formats as an existing key. 1860 This arrangement supports the development of new parameters while 1861 ensuring that zone files can be made interoperable. 1863 15.3.2. Initial contents 1865 The "Service Binding (SVCB) Parameter Registry" shall initially be 1866 populated with the registrations below: 1868 +=============+=================+=============+=========+===========+ 1869 | Number | Name |Meaning |Format |Change | 1870 | | | |Reference|Controller | 1871 +=============+=================+=============+=========+===========+ 1872 | 0 | mandatory |Mandatory |(This |IETF | 1873 | | |keys in this |document)| | 1874 | | |RR |Section 8| | 1875 +-------------+-----------------+-------------+---------+-----------+ 1876 | 1 | alpn |Additional |(This |IETF | 1877 | | |supported |document)| | 1878 | | |protocols |Section | | 1879 | | | |7.1 | | 1880 +-------------+-----------------+-------------+---------+-----------+ 1881 | 2 | no-default-alpn |No support |(This |IETF | 1882 | | |for default |document)| | 1883 | | |protocol |Section | | 1884 | | | |7.1 | | 1885 +-------------+-----------------+-------------+---------+-----------+ 1886 | 3 | port |Port for |(This |IETF | 1887 | | |alternative |document)| | 1888 | | |endpoint |Section | | 1889 | | | |7.2 | | 1890 +-------------+-----------------+-------------+---------+-----------+ 1891 | 4 | ipv4hint |IPv4 address |(This |IETF | 1892 | | |hints |document)| | 1893 | | | |Section | | 1894 | | | |7.4 | | 1895 +-------------+-----------------+-------------+---------+-----------+ 1896 | 5 | ech |Encrypted |(This |IETF | 1897 | | |ClientHello |document)| | 1898 | | |info |Section | | 1899 | | | |7.3 | | 1900 +-------------+-----------------+-------------+---------+-----------+ 1901 | 6 | ipv6hint |IPv6 address |(This |IETF | 1902 | | |hints |document)| | 1903 | | | |Section | | 1904 | | | |7.4 | | 1905 +-------------+-----------------+-------------+---------+-----------+ 1906 | 65280-65534 | N/A |Private Use |(This |IETF | 1907 | | | |document)| | 1908 +-------------+-----------------+-------------+---------+-----------+ 1909 | 65535 | N/A |Reserved |(This |IETF | 1910 | | |("Invalid |document)| | 1911 | | |key") | | | 1912 +-------------+-----------------+-------------+---------+-----------+ 1914 Table 1 1916 15.4. Other registry updates 1918 Per [Attrleaf], please add the following entry to the DNS Underscore 1919 Global Scoped Entry Registry: 1921 +=========+============+=================+=================+ 1922 | RR TYPE | _NODE NAME | Meaning | Reference | 1923 +=========+============+=================+=================+ 1924 | HTTPS | _https | HTTPS SVCB info | (This document) | 1925 +---------+------------+-----------------+-----------------+ 1927 Table 2 1929 16. Acknowledgments and Related Proposals 1931 There have been a wide range of proposed solutions over the years to 1932 the "CNAME at the Zone Apex" challenge proposed. These include 1933 [I-D.bellis-dnsop-http-record], [I-D.ietf-dnsop-aname], and others. 1935 Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thomson, Lucas 1936 Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, David 1937 Benjamin, Mark Andrews, Emily Stark, Eric Orth, Kyle Rose, Craig 1938 Taylor, Dan McArdle, Brian Dickson, Willem Toorop, Pieter Lexis, 1939 Puneet Sood, Olivier Poitrey, Mashooq Muhaimen, Tom Carpay, and many 1940 others for their feedback and suggestions on this draft. 1942 17. References 1944 17.1. Normative References 1946 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1947 "Transport Layer Security (TLS) Application-Layer Protocol 1948 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1949 July 2014, . 1951 [Attrleaf] Crocker, D., "Scoped Interpretation of DNS Resource 1952 Records through "Underscored" Naming of Attribute Leaves", 1953 BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, 1954 . 1956 [DoH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1957 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1958 . 1960 [DoT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1961 and P. Hoffman, "Specification for DNS over Transport 1962 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1963 2016, . 1965 [ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 1966 Encrypted Client Hello", Work in Progress, Internet-Draft, 1967 draft-ietf-tls-esni-14, 13 February 2022, 1968 . 1971 [HappyEyeballsV2] 1972 Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1973 Better Connectivity Using Concurrency", RFC 8305, 1974 DOI 10.17487/RFC8305, December 2017, 1975 . 1977 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 1978 Semantics", Work in Progress, Internet-Draft, draft-ietf- 1979 httpbis-semantics-19, 12 September 2021, 1980 . 1983 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1984 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1985 . 1987 [RFC1035] Mockapetris, P., "Domain names - implementation and 1988 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1989 November 1987, . 1991 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1992 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1993 DOI 10.17487/RFC1928, March 1996, 1994 . 1996 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1997 Requirement Levels", BCP 14, RFC 2119, 1998 DOI 10.17487/RFC2119, March 1997, 1999 . 2001 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 2002 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 2003 . 2005 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 2006 RFC 3225, DOI 10.17487/RFC3225, December 2001, 2007 . 2009 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 2010 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2011 2003, . 2013 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 2014 Schoenwaelder, "Textual Conventions for Internet Network 2015 Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, 2016 . 2018 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2019 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2020 . 2022 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2023 Specifications: ABNF", STD 68, RFC 5234, 2024 DOI 10.17487/RFC5234, January 2008, 2025 . 2027 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2028 Address Text Representation", RFC 5952, 2029 DOI 10.17487/RFC5952, August 2010, 2030 . 2032 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 2033 Extensions: Extension Definitions", RFC 6066, 2034 DOI 10.17487/RFC6066, January 2011, 2035 . 2037 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 2038 Beijnum, "DNS64: DNS Extensions for Network Address 2039 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 2040 DOI 10.17487/RFC6147, April 2011, 2041 . 2043 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 2044 the IPv6 Prefix Used for IPv6 Address Synthesis", 2045 RFC 7050, DOI 10.17487/RFC7050, November 2013, 2046 . 2048 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2049 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2050 DOI 10.17487/RFC7231, June 2014, 2051 . 2053 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 2054 and Registration Procedures for URI Schemes", BCP 35, 2055 RFC 7595, DOI 10.17487/RFC7595, June 2015, 2056 . 2058 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 2059 Kumari, "Client Subnet in DNS Queries", RFC 7871, 2060 DOI 10.17487/RFC7871, May 2016, 2061 . 2063 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2064 Writing an IANA Considerations Section in RFCs", BCP 26, 2065 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2066 . 2068 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2069 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2070 May 2017, . 2072 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2073 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2074 . 2076 [WebSocket] 2077 Fette, I. and A. Melnikov, "The WebSocket Protocol", 2078 RFC 6455, DOI 10.17487/RFC6455, December 2011, 2079 . 2081 17.2. Informative References 2083 [AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP 2084 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 2085 April 2016, . 2087 [DNAME] Rose, S. and W. Wijngaards, "DNAME Redirection in the 2088 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 2089 . 2091 [DNSTerm] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 2092 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 2093 January 2019, . 2095 [FETCH] "Fetch Living Standard", May 2020, 2096 . 2098 [HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 2099 Transport Security (HSTS)", RFC 6797, 2100 DOI 10.17487/RFC6797, November 2012, 2101 . 2103 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 2104 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 2105 quic-http-34, 2 February 2021, 2106 . 2109 [I-D.bellis-dnsop-http-record] 2110 Bellis, R., "A DNS Resource Record for HTTP", Work in 2111 Progress, Internet-Draft, draft-bellis-dnsop-http-record- 2112 00, 3 November 2018, 2113 . 2116 [I-D.ietf-dnsop-aname] 2117 Finch, T., Hunt, E., Dijk, P. V., Eden, A., and M. 2118 Mekking, "Address-specific DNS aliases (ANAME)", Work in 2119 Progress, Internet-Draft, draft-ietf-dnsop-aname-04, 8 2120 July 2019, . 2123 [RFC1912] Barr, D., "Common DNS Operational and Configuration 2124 Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996, 2125 . 2127 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 2128 DOI 10.17487/RFC6454, December 2011, 2129 . 2131 [SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2132 specifying the location of services (DNS SRV)", RFC 2782, 2133 DOI 10.17487/RFC2782, February 2000, 2134 . 2136 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2137 Resource Identifier (URI): Generic Syntax", STD 66, 2138 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2139 . 2141 Appendix A. Decoding text in zone files 2143 DNS zone files are capable of representing arbitrary octet sequences 2144 in basic ASCII text, using various delimiters and encodings. The 2145 algorithm for decoding these character-strings is defined in 2146 Section 5.1 of [RFC1035]. Here we summarize the allowed input to 2147 that algorithm, using ABNF: 2149 ; non-special is VCHAR minus DQUOTE, ";", "(", ")", and "\". 2150 non-special = %x21 / %x23-27 / %x2A-3A / %x3C-5B / %x5D-7E 2151 ; non-digit is VCHAR minus DIGIT 2152 non-digit = %x21-2F / %x3A-7E 2153 ; dec-octet is a number 0-255 as a three-digit decimal number. 2154 dec-octet = ( "0" / "1" ) 2DIGIT / 2155 "2" ( ( %x30-34 DIGIT ) / ( "5" %x30-35 ) ) 2156 escaped = "\" ( non-digit / dec-octet ) 2157 contiguous = 1*( non-special / escaped ) 2158 quoted = DQUOTE *( contiguous / ( ["\"] WSP ) ) DQUOTE 2159 char-string = contiguous / quoted 2161 The decoding algorithm allows char-string to represent any *OCTET, 2162 using quoting to group values (e.g., those with internal whitespace), 2163 and escaping to represent each non-printable octet as a single 2164 escaped sequence. In this document, this algorithm is referred to as 2165 "character-string decoding". The algorithm is the same as used by 2166 in RFC 1035, although the output length in this 2167 document is not limited to 255 octets. 2169 A.1. Decoding a comma-separated list 2171 In order to represent lists of items in zone files, this 2172 specification uses comma-separated lists. When the allowed items in 2173 the list cannot contain "," or "\", this is trivial. (For 2174 simplicity, empty items are not allowed.) A value-list parser that 2175 splits on "," and prohibits items containing "\" is sufficient to 2176 comply with all requirements in this document. This corresponds to 2177 the simple-comma-separated syntax: 2179 ; item-allowed is OCTET minus "," and "\". 2180 item-allowed = %x00-2B / %x2D-5B / %x5D-FF 2181 simple-item = 1*item-allowed 2182 simple-comma-separated = [simple-item *("," simple-item)] 2184 For implementations that allow "," and "\" in item values, the 2185 following escaping syntax applies: 2187 item = 1*OCTET 2188 escaped-item = 1*(item-allowed / "\," / "\\") 2189 comma-separated = [escaped-item *("," escaped-item)] 2191 Decoding of value-lists happens after character-string decoding. For 2192 example, consider these char-string SvcParamValues: 2194 "part1,part2,part3\\,part4\\\\" 2195 part1\,\p\a\r\t2\044part3\092,part4\092\\ 2196 These inputs are equivalent: character-string decoding either of them 2197 would produce the same value: 2199 part1,part2,part3\,part4\\ 2201 Applying comma-separated list decoding to this value would produce a 2202 list of three items: 2204 part1 2205 part2 2206 part3,part4\ 2208 Appendix B. HTTP Mapping Summary 2210 This table serves as a non-normative summary of the HTTP mapping for 2211 SVCB (Section 9). Future protocol mappings may provide a similar 2212 summary table. 2214 +==========================+======================+ 2215 +==========================+======================+ 2216 | *Mapped scheme* | "https" | 2217 +--------------------------+----------------------+ 2218 | *Other affected schemes* | "http", "wss", "ws", | 2219 | | (other HTTP-based) | 2220 +--------------------------+----------------------+ 2221 | *RR type* | HTTPS (65) | 2222 +--------------------------+----------------------+ 2223 | *Name prefix* | None for port 443, | 2224 | | else _$PORT._https | 2225 +--------------------------+----------------------+ 2226 | *Automatically Mandatory | port, no-default- | 2227 | Keys* | alpn | 2228 +--------------------------+----------------------+ 2229 | *SvcParam defaults* | alpn: ["http/1.1"] | 2230 +--------------------------+----------------------+ 2231 | *Special behaviors* | HTTP to HTTPS | 2232 | | upgrade | 2233 +--------------------------+----------------------+ 2234 | *Keys that records must | None | 2235 | include* | | 2236 +--------------------------+----------------------+ 2238 Table 3 2240 Appendix C. Comparison with alternatives 2242 The SVCB and HTTPS RR types closely resemble, and are inspired by, 2243 some existing record types and proposals. A complaint with all of 2244 the alternatives is that web clients have seemed unenthusiastic about 2245 implementing them. The hope here is that by providing an extensible 2246 solution that solves multiple problems we will overcome the inertia 2247 and have a path to achieve client implementation. 2249 C.1. Differences from the SRV RR type 2251 An SRV record [SRV] can perform a similar function to the SVCB 2252 record, informing a client to look in a different location for a 2253 service. However, there are several differences: 2255 * SRV records are typically mandatory, whereas SVCB is intended to 2256 be optional when used with pre-existing protocols. 2258 * SRV records cannot instruct the client to switch or upgrade 2259 protocols, whereas SVCB can signal such an upgrade (e.g. to 2260 HTTP/2). 2262 * SRV records are not extensible, whereas SVCB and HTTPS RRs can be 2263 extended with new parameters. 2265 * SRV records specify a "weight" for unbalanced randomized load- 2266 balancing. SVCB only supports balanced randomized load-balancing, 2267 although weights could be added via a future SvcParam. 2269 C.2. Differences from the proposed HTTP record 2271 Unlike [I-D.bellis-dnsop-http-record], this approach is extensible to 2272 cover Alt-Svc and Encrypted ClientHello use-cases. Like that 2273 proposal, this addresses the zone apex CNAME challenge. 2275 Like that proposal, it remains necessary to continue to include 2276 address records at the zone apex for legacy clients. 2278 C.3. Differences from the proposed ANAME record 2280 Unlike [I-D.ietf-dnsop-aname], this approach is extensible to cover 2281 Alt-Svc and ECH use-cases. This approach also does not require any 2282 changes or special handling on either authoritative or primary 2283 servers, beyond optionally returning in-bailiwick additional records. 2285 Like that proposal, this addresses the zone apex CNAME challenge for 2286 clients that implement this. 2288 However, with this SVCB proposal, it remains necessary to continue to 2289 include address records at the zone apex for legacy clients. If 2290 deployment of this standard is successful, the number of legacy 2291 clients will fall over time. As the number of legacy clients 2292 declines, the operational effort required to serve these users 2293 without the benefit of SVCB indirection should fall. Server 2294 operators can easily observe how much traffic reaches this legacy 2295 endpoint, and may remove the apex's address records if the observed 2296 legacy traffic has fallen to negligible levels. 2298 C.4. Comparison with separate RR types for AliasMode and ServiceMode 2300 Abstractly, functions of AliasMode and ServiceMode are independent, 2301 so it might be tempting to specify them as separate RR types. 2302 However, this would result in a serious performance impairment, 2303 because clients cannot rely on their recursive resolver to follow 2304 SVCB aliases (unlike CNAME). Thus, clients would have to issue 2305 queries for both RR types in parallel, potentially at each step of 2306 the alias chain. Recursive resolvers that implement the 2307 specification would, upon receipt of a ServiceMode query, emit both a 2308 ServiceMode and an AliasMode query to the authoritative. Thus, 2309 splitting the RR type would double, or in some cases triple, the load 2310 on clients and servers, and would not reduce implementation 2311 complexity. 2313 Appendix D. Test vectors 2315 These test vectors only contain the RDATA portion of SVCB/HTTPS 2316 records in presentation format, generic format ([RFC3597]) and wire 2317 format. The wire format uses hexadecimal (\xNN) for each non-ascii 2318 byte. As the wireformat is long, it is broken into several lines. 2320 D.1. AliasMode 2322 example.com. HTTPS 0 foo.example.com. 2324 \# 19 ( 2325 00 00 ; priority 2326 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2327 ) 2329 \x00\x00 # priority 2330 \x03foo\x07example\x03com\x00 # target 2332 Figure 2: AliasMode 2334 D.2. ServiceMode 2335 example.com. SVCB 1 . 2337 \# 3 ( 2338 00 01 ; priority 2339 00 ; target (root label) 2340 ) 2342 \x00\x01 # priority 2343 \x00 # target, root label 2345 Figure 3: TargetName is "." 2347 example.com. SVCB 16 foo.example.com. port=53 2349 \# 25 ( 2350 00 10 ; priority 2351 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2352 00 03 ; key 3 2353 00 02 ; length 2 2354 00 35 ; value 2355 ) 2357 \x00\x10 # priority 2358 \x03foo\x07example\x03com\x00 # target 2359 \x00\x03 # key 3 2360 \x00\x02 # length: 2 bytes 2361 \x00\x35 # value 2363 Figure 4: Specifies a port 2365 example.com. SVCB 1 foo.example.com. key667=hello 2367 \# 28 ( 2368 00 01 ; priority 2369 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2370 02 9b ; key 667 2371 00 05 ; length 5 2372 68 65 6c 6c 6f ; value 2373 ) 2375 \x00\x01 # priority 2376 \x03foo\x07example\x03com\x00 # target 2377 \x02\x9b # key 667 2378 \x00\x05 # length 5 2379 hello # value 2381 Figure 5: A generic key and unquoted value 2383 example.com. SVCB 1 foo.example.com. key667="hello\210qoo" 2385 \# 32 ( 2386 00 01 ; priority 2387 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2388 02 9b ; key 667 2389 00 09 ; length 9 2390 68 65 6c 6c 6f d2 71 6f 6f ; value 2391 ) 2393 \x00\x01 # priority 2394 \x03foo\x07example\x03com\x00 # target 2395 \x02\x9b # key 667 2396 \x00\x09 # length 9 2397 hello\xd2qoo # value 2399 Figure 6: A generic key and quoted value with a decimal escape 2401 example.com. SVCB 1 foo.example.com. ( 2402 ipv6hint="2001:db8::1,2001:db8::53:1" 2403 ) 2405 \# 55 ( 2406 00 01 ; priority 2407 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2408 00 06 ; key 6 2409 00 20 ; length 32 2410 20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01 ; first address 2411 20 01 0d b8 00 00 00 00 00 00 00 00 00 53 00 01 ; second address 2412 ) 2414 \x00\x01 # priority 2415 \x03foo\x07example\x03com\x00 # target 2416 \x00\x06 # key 6 2417 \x00\x20 # length 32 2418 \x20\x01\x0d\xb8\x00\x00\x00\x00 2419 \x00\x00\x00\x00\x00\x00\x00\x01 # first address 2420 \x20\x01\x0d\xb8\x00\x00\x00\x00 2421 \x00\x00\x00\x00\x00\x53\x00\x01 # second address 2423 Figure 7: Two quoted IPv6 hints 2425 example.com. SVCB 1 example.com. ipv6hint="2001:db8:122:344::192.0.2.33" 2427 \# 35 ( 2428 00 01 ; priority 2429 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2430 00 06 ; key 6 2431 00 10 ; length 16 2432 20 01 0d b8 01 22 03 44 00 00 00 00 c0 00 02 21 ; address 2433 ) 2435 \x00\x01 # priority 2436 \x07example\x03com\x00 # target 2437 \x00\x06 # key 6 2438 \x00\x10 # length 16 2439 \x20\x01\x0d\xb8\x01\x22\x03\x44 2440 \x00\x00\x00\x00\xc0\x00\x02\x21 # address 2442 Figure 8: An IPv6 hint using the embedded IPv4 syntax 2444 example.com. SVCB 16 foo.example.org. ( 2445 alpn=h2,h3-19 mandatory=ipv4hint,alpn 2446 ipv4hint=192.0.2.1 2447 ) 2449 \# 48 ( 2450 00 10 ; priority 2451 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target 2452 00 00 ; key 0 2453 00 04 ; param length 4 2454 00 01 ; value: key 1 2455 00 04 ; value: key 4 2456 00 01 ; key 1 2457 00 09 ; param length 9 2458 02 ; alpn length 2 2459 68 32 ; alpn value 2460 05 ; alpn length 5 2461 68 33 2d 31 39 ; alpn value 2462 00 04 ; key 4 2463 00 04 ; param length 4 2464 c0 00 02 01 ; param value 2465 ) 2467 \x00\x10 # priority 2468 \x03foo\x07example\x03org\x00 # target 2469 \x00\x00 # key 0 2470 \x00\x04 # param length 4 2471 \x00\x01 # value: key 1 2472 \x00\x04 # value: key 4 2473 \x00\x01 # key 1 2474 \x00\x09 # param length 9 2475 \x02 # alpn length 2 2476 h2 # alpn value 2477 \x05 # alpn length 5 2478 h3-19 # alpn value 2479 \x00\x04 # key 4 2480 \x00\x04 # param length 4 2481 \xc0\x00\x02\x01 # param value 2483 Figure 9: SvcParamKey ordering is arbitrary in presentation 2484 format but sorted in wire format 2486 example.com. SVCB 16 foo.example.org. alpn="f\\\\oo\\,bar,h2" 2487 example.com. SVCB 16 foo.example.org. alpn=f\\\092oo\092,bar,h2 2489 \# 35 ( 2490 00 10 ; priority 2491 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target 2492 00 01 ; key 1 2493 00 0c ; param length 12 2494 08 ; alpn length 8 2495 66 5c 6f 6f 2c 62 61 72 ; alpn value 2496 02 ; alpn length 2 2497 68 32 ; alpn value 2498 ) 2500 \x00\x10 # priority 2501 \x03foo\x07example\x03org\x00 # target 2502 \x00\x01 # key 1 2503 \x00\x0c # param length 12 2504 \x08 # alpn length 8 2505 f\oo,bar # alpn value 2506 \x02 # alpn length 2 2507 h2 # alpn value 2509 Figure 10: An alpn value with an escaped comma and an escaped 2510 backslash in two presentation formats 2512 D.3. Failure cases 2514 This subsection contains test vectors which are not compliant with 2515 this document. The various reasons for non-compliance are explained 2516 with each example. 2518 example.com. SVCB 1 foo.example.com. ( 2519 key123=abc key123=def 2520 ) 2522 Figure 11: Multiple instances of the same SvcParamKey 2524 example.com. SVCB 1 foo.example.com. mandatory 2525 example.com. SVCB 1 foo.example.com. alpn 2526 example.com. SVCB 1 foo.example.com. port 2527 example.com. SVCB 1 foo.example.com. ipv4hint 2528 example.com. SVCB 1 foo.example.com. ipv6hint 2530 Figure 12: Missing SvcParamValues that must be nonempty 2532 example.com. SVCB 1 foo.example.com. no-default-alpn=abc 2533 Figure 13: The "no-default-alpn" SvcParamKey value must be empty 2535 example.com. SVCB 1 foo.example.com. mandatory=key123 2537 Figure 14: A mandatory SvcParam is missing 2539 example.com. SVCB 1 foo.example.com. mandatory=mandatory 2541 Figure 15: The "mandatory" SvcParamKey must not be included in 2542 the mandatory list 2544 example.com. SVCB 1 foo.example.com. ( 2545 mandatory=key123,key123 key123=abc 2546 ) 2548 Figure 16: Multiple instances of the same SvcParamKey in the 2549 mandatory list 2551 Appendix E. Change history 2553 (This section to be removed by the RFC editor.) 2555 * draft-ietf-dnsop-svcb-https-10 2557 - Clarify rationale for two recommendations 2559 * draft-ietf-dnsop-svcb-https-09 2561 - Extensive adjustments based on IESG reviews, including: 2563 o IANA registry changed to Expert Review policy 2565 o Adjustments to the use of normative language 2567 o Revised and expanded description of HSTS behavior 2569 o Expanded discussion of CNAME handling 2571 o Discussion of SvcParams in AliasMode records 2573 o Restructured ABNF for comma-separated lists 2575 o Additional references and many other minor clarifications 2577 - Other changes include: 2579 o New section on interaction with DNS64 2580 o New text on the interpretation of wildcard owner names 2582 o Adjusted guidance on default ALPN enforcement 2584 o Removed mention of IPv4-mapped IPv6 2586 * draft-ietf-dnsop-svcb-https-08 2588 - Extensive structural and editorial adjustments based on area 2589 reviews, including: 2591 o A new section on SVCB-compatible record types 2593 o Reorganized description of client behavior 2595 o Test vectors are now in titled figures 2597 o Adjusted mapping summary 2599 o Improve description of rules for resolver handling of 2600 invalid SvcParamValues. 2602 - New text on cross-transport fallback (e.g. QUIC vs. TCP) 2604 - Improved explanation of use with domain-oriented transport 2605 proxies 2607 - HTTP terminology adjusted to match draft-ietf-httpbis-semantics 2609 - Improved and corrected IANA instructions 2611 * draft-ietf-dnsop-svcb-https-07 2613 - Editorial improvements following AD review. 2615 * draft-ietf-dnsop-svcb-https-06 2617 - Add requirements for HTTPS origins that also use Alt-Svc 2619 - Remove requirement for comma-escaping related to unusual ALPN 2620 values 2622 - Allow resolvers to reject invalid SvcParamValues, with 2623 additional guidance 2625 * draft-ietf-dnsop-svcb-https-05 2626 - Specify interaction with EDNS Client Subnet and Additional 2627 section caching 2629 - Rename "echconfig" to "ech" 2631 - Add a suite of test vectors (both valid and invalid) and more 2632 examples 2634 - Clarify requirements for resolvers' (non-)use of SvcParams 2636 - Clarify guidance regarding default ALPN values 2638 * draft-ietf-dnsop-svcb-https-04 2640 - Simplify the IANA instructions (pure First Come First Served) 2642 - Recommend against publishing chains of >8 aliases 2644 - Clarify requirements for using SVCB with a transport proxy 2646 - Adjust guidance for Port Prefix Naming 2648 - Minor editorial updates 2650 * draft-ietf-dnsop-svcb-https-03 2652 - Simplified escaping of comma-separated values 2654 - Reorganized client requirements 2656 - Added a warning about port filtering for cross-protocol attacks 2658 - Clarified self-consistency rules for SvcParams 2660 - Added a non-normative mapping summary table for HTTPS 2662 * draft-ietf-dnsop-svcb-https-02 2664 - Added a Privacy Considerations section 2666 - Adjusted resolution fallback description 2668 - Clarified status of SvcParams in AliasMode 2670 - Improved advice on zone structuring and use with Alt-Svc 2672 - Improved examples, including a new Multi-CDN example 2673 - Reorganized text on value-list parsing and SvcPriority 2675 - Improved phrasing and other editorial improvements throughout 2677 * draft-ietf-dnsop-svcb-https-01 2679 - Added a "mandatory" SvcParamKey 2681 - Added the ability to indicate that a service does not exist 2683 - Adjusted resolution and ALPN algorithms 2685 - Major terminology revisions for "origin" and CamelCase names 2687 - Revised ABNF 2689 - Include allocated RR type numbers 2691 - Various corrections, explanations, and recommendations 2693 * draft-ietf-dnsop-svcb-https-00 2695 - Rename HTTPSSVC RR to HTTPS RR 2697 - Rename "an SVCB" to "a SVCB" 2699 - Removed "design considerations and open issues" section and 2700 some other "to be removed" text 2702 * draft-ietf-dnsop-svcb-httpssvc-03 2704 - Revised chain length limit requirements 2706 - Revised IANA registry rules for SvcParamKeys 2708 - Require HTTPS clients to implement SNI 2710 - Update terminology for Encrypted ClientHello 2712 - Clarifications: non-default ports, transport proxies, HSTS 2713 procedure, WebSocket behavior, wire format, IP hints, inner/ 2714 outer ClientHello with ECH 2716 - Various textual and ABNF corrections 2718 * draft-ietf-dnsop-svcb-httpssvc-02 2720 - All changes to Alt-Svc have been removed 2721 - Expanded and reorganized examples 2723 - Priority zero is now the definition of AliasForm 2725 - Repeated SvcParamKeys are no longer allowed 2727 - The "=" sign may be omitted in a key=value pair if the value is 2728 also empty 2730 - In the wire format, SvcParamKeys must be in sorted order 2732 - New text regarding how to handle resolution timeouts 2734 - Expanded description of recursive resolver behavior 2736 - Much more precise description of the intended ALPN behavior 2738 - Match the HSTS specification's language on HTTPS enforcement 2740 - Removed 'esniconfig=""' mechanism and simplified ESNI 2741 connection logic 2743 * draft-ietf-dnsop-svcb-httpssvc-01 2745 - Reduce the emphasis on conversion between HTTPSSVC and Alt-Svc 2747 - Make the "untrusted channel" concept more precise. 2749 - Make SvcFieldPriority = 0 the definition of AliasForm, instead 2750 of a requirement. 2752 * draft-ietf-dnsop-svcb-httpssvc-00 2754 - Document an optimization for optimistic pre-connection. (Chris 2755 Wood) 2757 - Relax IP hint handling requirements. (Eric Rescorla) 2759 * draft-nygren-dnsop-svcb-httpssvc-00 2761 - Generalize to an SVCB record, with special-case handling for 2762 Alt-Svc and HTTPS separated out to dedicated sections. 2764 - Split out a separate HTTPSSVC record for the HTTPS use-case. 2766 - Remove the explicit SvcRecordType=0/1 and instead make the 2767 AliasForm vs ServiceForm be implicit. This was based on 2768 feedback recommending against subtyping RR type. 2770 - Remove one optimization. 2772 * draft-nygren-httpbis-httpssvc-03 2774 - Change redirect type for HSTS-style behavior from 302 to 307 to 2775 reduce ambiguities. 2777 * draft-nygren-httpbis-httpssvc-02 2779 - Remove the redundant length fields from the wire format. 2781 - Define a SvcDomainName of "." for SvcRecordType=1 as being the 2782 HTTPSSVC RRNAME. 2784 - Replace "hq" with "h3". 2786 * draft-nygren-httpbis-httpssvc-01 2788 - Fixes of record name. Replace references to "HTTPSVC" with 2789 "HTTPSSVC". 2791 * draft-nygren-httpbis-httpssvc-00 2793 - Initial version 2795 Authors' Addresses 2797 Ben Schwartz 2798 Google 2799 Email: bemasc@google.com 2801 Mike Bishop 2802 Akamai Technologies 2803 Email: mbishop@evequefou.be 2805 Erik Nygren 2806 Akamai Technologies 2807 Email: erik+ietf@nygren.org