idnits 2.17.1 draft-ietf-dnsop-svcb-https-09.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 (6 May 2022) is 721 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: 7 November 2022 E. Nygren 6 Akamai Technologies 7 6 May 2022 9 Service binding and parameter specification via the DNS (DNS SVCB and 10 HTTPS RRs) 11 draft-ietf-dnsop-svcb-https-09 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 7 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. Zone-file implementations 579 SHOULD enforce self-consistency. Clients MUST reject any RR whose 580 recognized SvcParams are not self-consistent, and MAY reject the 581 entire RRSet. 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. 690 If DNS responses are not cryptographically protected, clients MAY 691 treat SVCB resolution failure as fatal or nonfatal. 693 If the client is unable to complete SVCB resolution due to its chain 694 length limit, the client MUST fall back to the authority endpoint, as 695 if the origin's SVCB record did not exist. 697 3.2. Clients using a Proxy 699 Clients using a domain-oriented transport proxy like HTTP CONNECT 700 ([RFC7231], Section 4.3.6) or SOCKS5 ([RFC1928]) have the option to 701 use named destinations, in which case the client does not perform any 702 A or AAAA queries for destination domains. If the client is 703 configured to use named destinations with a proxy that does not 704 provide SVCB query capability (e.g. through an affiliated DNS 705 resolver), the client would have to perform SVCB resolution 706 separately, likely disclosing the destinations to additional parties 707 than just the proxy. Clients in this configuration SHOULD arrange 708 for a separate SVCB resolution procedure with appropriate privacy 709 properties. If this is not possible, SVCB-optional clients MUST 710 disable SVCB resolution entirely, and SVCB-required clients MUST 711 treat the configuration as invalid. 713 If the client does use SVCB and named destinations, the client SHOULD 714 follow the standard SVCB resolution process, selecting the smallest- 715 SvcPriority option that is compatible with the client and the proxy. 716 When connecting using a SVCB record, clients MUST provide the final 717 TargetName and port to the proxy, which will perform any required A 718 and AAAA lookups. 720 This arrangement has several benefits: 722 * Compared to disabling SVCB: 724 - It allows the client to use the SvcParams, if present, which 725 are only usable with a specific TargetName. The SvcParams may 726 include information that enhances performance (e.g. alpn) and 727 privacy (e.g. ech). 729 - It allows the service to delegate the apex domain. 731 * Compared to providing the proxy with an IP address: 733 - It allows the proxy to select between IPv4 and IPv6 addresses 734 for the server according to its configuration. 736 - It ensures that the proxy receives addresses based on its 737 network geolocation, not the client's. 739 - It enables faster fallback for TCP destinations with multiple 740 addresses of the same family. 742 4. DNS Server Behavior 744 4.1. Authoritative servers 746 When replying to a SVCB query, authoritative DNS servers SHOULD 747 return A, AAAA, and SVCB records in the Additional Section for any 748 TargetNames that are in the zone. If the zone is signed, the server 749 SHOULD also include positive or negative DNSSEC responses for these 750 records in the Additional section. 752 See Section 4.4 for exceptions. 754 4.2. Recursive resolvers 756 Whether the recursive resolver is aware of SVCB or not, the normal 757 response construction process (i.e. unknown RR type resolution under 758 [RFC3597]) generates the Answer section of the response. Recursive 759 resolvers that are aware of SVCB SHOULD help the client to execute 760 the procedure in Section 3 with minimum overall latency by 761 incorporating additional useful information into the Additional 762 section of the response as follows: 764 1. Incorporate the results of SVCB resolution. If the recursive 765 resolver's local chain length limit (which may be different from 766 the client's limit) has been reached, terminate. 768 2. If any of the resolved SVCB records are in AliasMode, choose one 769 of them at random, and resolve SVCB, A, and AAAA records for its 770 TargetName. 772 * If any SVCB records are resolved, go to step 1. 774 * Otherwise, incorporate the results of A and AAAA resolution, 775 and terminate. 777 3. All the resolved SVCB records are in ServiceMode. Resolve A and 778 AAAA queries for each TargetName (or for the owner name if 779 TargetName is "."), incorporate all the results, and terminate. 781 In this procedure, "resolve" means the resolver's ordinary recursive 782 resolution procedure, as if processing a query for that RRSet. This 783 includes following any aliases that the resolver would ordinarily 784 follow (e.g. CNAME, DNAME [DNAME]). Errors or anomalies in 785 obtaining additional records MAY cause this process to terminate, but 786 MUST NOT themselves cause the resolver to send a failure response. 788 See Section 2.4.2 for additional safeguards for recursive resolvers 789 to implement to mitigate loops. 791 See Section 5.2 for possible optimizations of this procedure. 793 4.2.1. DNS64 795 DNS64 resolvers synthesize responses to AAAA queries for names that 796 only have an A record (Section 5.1.7 of [RFC6147]). SVCB-aware DNS64 797 resolvers SHOULD apply the same synthesis logic when resolving AAAA 798 records for the TargetName for inclusion as Additionals (Step 2 in 799 Section 4.2), and MAY omit the Additional A records. 801 DNS64 resolvers MUST NOT extrapolate the AAAA synthesis logic to the 802 IP hints in the SvcParams (Section 7.4). Modifying the IP hints 803 would break DNSSEC validation for the SVCB record and would not 804 improve performance when the above recommendation is implemented. 806 4.3. General requirements 808 Recursive resolvers MUST be able to convey SVCB records with 809 unrecognized SvcParamKeys, and MAY treat the entire SvcParams portion 810 of the record as opaque, even if the contents are invalid. 811 Alternatively, recursive resolvers MAY report an error such as 812 SERVFAIL to avoid returning a SvcParamValue that is invalid according 813 to the SvcParam's specification. For complex value types whose 814 interpretation might differ between implementations or have 815 additional future allowed values added (e.g. URIs or "alpn"), 816 resolvers SHOULD limit validation to specified constraints. 818 When responding to a query that includes the DNSSEC OK bit 819 ([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers 820 MUST accompany each RRSet in the Additional section with the same 821 DNSSEC-related records that they would send when providing that RRSet 822 as an Answer (e.g. RRSIG, NSEC, NSEC3). 824 According to Section 5.4.1 of [RFC2181], "Unauthenticated RRs 825 received and cached from ... the additional data section ... should 826 not be cached in such a way that they would ever be returned as 827 answers to a received query. They may be returned as additional 828 information where appropriate.". Recursive resolvers therefore MAY 829 cache records from the Additional section for use in populating 830 Additional section responses, and MAY cache them for general use if 831 they are authenticated by DNSSEC. 833 4.4. EDNS Client Subnet (ECS) 835 The EDNS Client Subnet option (ECS, [RFC7871]) allows recursive 836 resolvers to request IP addresses that are suitable for a particular 837 client IP range. SVCB records may contain IP addresses (in ipv*hint 838 SvcParams), or direct users to a subnet-specific TargetName, so 839 recursive resolvers SHOULD include the same ECS option in SVCB 840 queries as in A/AAAA queries. 842 According to Section 7.3.1 of [RFC7871], "Any records from [the 843 Additional section] MUST NOT be tied to a network". Accordingly, 844 when processing a response whose QTYPE is SVCB-compatible, resolvers 845 SHOULD treat any records in the Additional section as having SOURCE 846 PREFIX-LENGTH zero and SCOPE PREFIX-LENGTH as specified in the ECS 847 option. Authoritative servers MUST omit such records if they are not 848 suitable for use by any stub resolvers that set SOURCE PREFIX-LENGTH 849 to zero. This will cause the resolver to perform a follow-up query 850 that can receive properly tailored ECS. (This is similar to the 851 usage of CNAME with ECS discussed in [RFC7871], Section 7.2.1.) 853 Authoritative servers that omit Additional records can avoid the 854 added latency of a follow-up query by following the advice in 855 Section 11.2. 857 5. Performance optimizations 859 For optimal performance (i.e. minimum connection setup time), clients 860 SHOULD implement a client-side DNS cache. Responses in the 861 Additional section of a SVCB response SHOULD be placed in cache 862 before performing any follow-up queries. With this behavior, and 863 conforming DNS servers, using SVCB does not add network latency to 864 connection setup. 866 To improve performance when using a non-conforming recursive 867 resolver, clients SHOULD issue speculative A and/or AAAA queries in 868 parallel with each SVCB query, based on a predicted value of 869 TargetName (see Section 11.2). 871 After a ServiceMode RRSet is received, clients MAY try more than one 872 option in parallel, and MAY prefetch A and AAAA records for multiple 873 TargetNames. 875 5.1. Optimistic pre-connection and connection reuse 877 If an address response arrives before the corresponding SVCB 878 response, the client MAY initiate a connection as if the SVCB query 879 returned NODATA, but MUST NOT transmit any information that could be 880 altered by the SVCB response until it arrives. For example, a TLS 881 ClientHello can be altered by the "ech" value of a SVCB response 882 (Section 7.3). Clients implementing this optimization SHOULD wait 883 for 50 milliseconds before starting optimistic pre-connection, as per 884 the guidance in [HappyEyeballsV2]. 886 A SVCB record is consistent with a connection if the client would 887 attempt an equivalent connection when making use of that record. If 888 a SVCB record is consistent with an active or in-progress connection 889 C, the client MAY prefer that record and use C as its connection. 890 For example, suppose the client receives this SVCB RRSet for a 891 protocol that uses TLS over TCP: 893 _1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. ( 894 ech="111..." ipv6hint=2001:db8::1 port=1234 ) 895 SVCB 2 svc2.example.net. ( 896 ech="222..." ipv6hint=2001:db8::2 port=1234 ) 898 If the client has an in-progress TCP connection to 899 [2001:db8::2]:1234, it MAY proceed with TLS on that connection using 900 ech="222...", even though the other record in the RRSet has higher 901 priority. 903 If none of the SVCB records are consistent with any active or in- 904 progress connection, clients proceed with connection establishment as 905 described in Section 3. 907 5.2. Generating and using incomplete responses 909 When following the procedure in Section 4.2, recursive resolvers MAY 910 terminate the procedure early and produce a reply that omits some of 911 the associated RRSets. This is REQUIRED when the chain length limit 912 is reached (Section 4.2 step 1), but might also be appropriate when 913 the maximum response size is reached, or when responding before fully 914 chasing dependencies would improve performance. When omitting 915 certain RRSets, recursive resolvers SHOULD prioritize information for 916 smaller-SvcPriority records. 918 As discussed in Section 3, clients MUST be able to fetch additional 919 information that is required to use a SVCB record, if it is not 920 included in the initial response. As a performance optimization, if 921 some of the SVCB records in the response can be used without 922 requiring additional DNS queries, the client MAY prefer those 923 records, regardless of their priorities. 925 6. SVCB-compatible 927 An RR type is called "SVCB-compatible" if it permits an 928 implementation that is identical to SVCB in its: 930 * RDATA presentation format 932 * RDATA wire format 934 * IANA registry used for SvcParamKeys 936 * Authoritative server Additional Section processing 938 * Recursive resolution process 940 * Relevant Class (i.e. Internet ("IN") [RFC1035]) 942 This allows authoritative and recursive DNS servers to apply 943 identical processing to all SVCB-compatible RR types. 945 All other behaviors described as applying to the SVCB RR also apply 946 to all SVCB-compatible RR types unless explicitly stated otherwise. 947 When following an AliasMode record (Section 2.4.2) of RR type $T , 948 the followup query to the TargetName MUST also be for type $T. 950 This document defines one SVCB-compatible RR type (other than SVCB 951 itself): the HTTPS RR type (Section 9), which avoids Attrleaf label 952 prefixes [Attrleaf] in order to improve compatibility with wildcards 953 and CNAMEs, which are widely used with HTTP. 955 Standards authors should consider carefully whether to use SVCB or 956 define a new SVCB-compatible RR type, as this choice cannot easily be 957 reversed after deployment. 959 7. Initial SvcParamKeys 961 A few initial SvcParamKeys are defined here. These keys are useful 962 for the "https" scheme, and most are expected to be generally 963 applicable to other schemes as well. 965 Each new protocol mapping document MUST specify which keys are 966 applicable and safe to use. Protocol mappings MAY alter the 967 interpretation of SvcParamKeys but MUST NOT alter their presentation 968 or wire formats. 970 7.1. "alpn" and "no-default-alpn" 972 The "alpn" and "no-default-alpn" SvcParamKeys together indicate the 973 set of Application Layer Protocol Negotiation (ALPN) protocol 974 identifiers [ALPN] and associated transport protocols supported by 975 this service endpoint (the "SVCB ALPN set"). 977 As with Alt-Svc [AltSvc], each ALPN protocol identifier is used to 978 identify the application protocol and associated suite of protocols 979 supported by the endpoint (the "protocol suite"). The presence of an 980 ALPN protocol identifier in the SVCB ALPN set indicates that this 981 service endpoint, described by TargetName and the other parameters 982 (e.g. "port") offers service with the protocol suite associated with 983 this ALPN identifier. 985 Clients filter the set of ALPN identifiers to match the protocol 986 suites they support, and this informs the underlying transport 987 protocol used (such as QUIC-over-UDP or TLS-over-TCP). ALPN protocol 988 identifiers that do not uniquely identify a protocol suite (e.g. an 989 Identification Sequence that can be used with both TLS and DTLS) are 990 not compatible with this SvcParamKey and MUST NOT be included in the 991 SVCB ALPN set. 993 7.1.1. Representation 995 ALPNs are identified by their registered "Identification Sequence" 996 (alpn-id), which is a sequence of 1-255 octets. 998 alpn-id = 1*255OCTET 1000 For "alpn", the presentation value SHALL be a comma-separated list 1001 (Appendix A.1) of one or more alpn-ids. Zone file implementations 1002 MAY disallow the "," and "\" characters instead of implementing the 1003 value-list escaping procedure, relying on the opaque key format (e.g. 1004 key1=\002h2) in the event that these characters are needed. 1006 The wire format value for "alpn" consists of at least one alpn-id 1007 prefixed by its length as a single octet, and these length-value 1008 pairs are concatenated to form the SvcParamValue. These pairs MUST 1009 exactly fill the SvcParamValue; otherwise, the SvcParamValue is 1010 malformed. 1012 For "no-default-alpn", the presentation and wire format values MUST 1013 be empty. When "no-default-alpn" is specified in an RR, "alpn" must 1014 also be specified in order for the RR to be "self-consistent" 1015 (Section 2.4.3). 1017 Each scheme that uses this SvcParamKey defines a "default set" of 1018 ALPNs that are supported by nearly all clients and servers, which MAY 1019 be empty. To determine the SVCB ALPN set, the client starts with the 1020 list of alpn-ids from the "alpn" SvcParamKey, and adds the default 1021 set unless the "no-default-alpn" SvcParamKey is present. 1023 7.1.2. Use 1025 To establish a connection to the endpoint, clients MUST 1027 1. Let SVCB-ALPN-Intersection be the set of protocols in the SVCB 1028 ALPN set that the client supports. 1030 2. Let Intersection-Transports be the set of transports (e.g. TLS, 1031 DTLS, QUIC) implied by the protocols in SVCB-ALPN-Intersection. 1033 3. For each transport in Intersection-Transports, construct a 1034 ProtocolNameList containing the Identification Sequences of all 1035 the client's supported ALPN protocols for that transport, without 1036 regard to the SVCB ALPN set. 1038 For example, if the SVCB ALPN set is ["http/1.1", "h3"], and the 1039 client supports HTTP/1.1, HTTP/2, and HTTP/3, the client could 1040 attempt to connect using TLS over TCP with a ProtocolNameList of 1041 ["http/1.1", "h2"], and could also attempt a connection using QUIC, 1042 with a ProtocolNameList of ["h3"]. 1044 Once the client has constructed a ClientHello, protocol negotiation 1045 in that handshake proceeds as specified in [ALPN], without regard to 1046 the SVCB ALPN set. 1048 Clients MAY implement a fallback procedure, using a less-preferred 1049 transport if more-preferred transports fail to connect. This 1050 fallback behavior is vulnerable to manipulation by a network attacker 1051 who blocks the more-preferred transports, but it may be necessary for 1052 compatibility with existing networks. 1054 With this procedure in place, an attacker who can modify DNS and 1055 network traffic can prevent a successful transport connection, but 1056 cannot otherwise interfere with ALPN protocol selection. This 1057 procedure also ensures that each ProtocolNameList includes at least 1058 one protocol from the SVCB ALPN set. 1060 Clients SHOULD NOT attempt connection to a service endpoint whose 1061 SVCB ALPN set does not contain any supported protocols. 1063 To ensure consistency of behavior, clients MAY reject the entire SVCB 1064 RRSet and fall back to basic connection establishment if all of the 1065 compatible RRs indicate "no-default-alpn", even if connection could 1066 have succeeded using a non-default alpn. 1068 Zone operators SHOULD ensure that at least one RR in each RRSet 1069 supports the default transports. This enables compatibility with the 1070 greatest number of clients. 1072 7.2. "port" 1074 The "port" SvcParamKey defines the TCP or UDP port that should be 1075 used to reach this alternative endpoint. If this key is not present, 1076 clients SHALL use the authority endpoint's port number. 1078 The presentation value of the SvcParamValue is a single decimal 1079 integer between 0 and 65535 in ASCII. Any other value (e.g. an empty 1080 value) is a syntax error. To enable simpler parsing, this SvcParam 1081 MUST NOT contain escape sequences. 1083 The wire format of the SvcParamValue is the corresponding 2 octet 1084 numeric value in network byte order. 1086 If a port-restricting firewall is in place between some client and 1087 the service endpoint, changing the port number might cause that 1088 client to lose access to the service, so operators should exercise 1089 caution when using this SvcParamKey to specify a non-default port. 1091 7.3. "ech" 1093 The SvcParamKey to enable Encrypted ClientHello (ECH) is "ech". Its 1094 value is defined in Section 10. It is applicable to most TLS-based 1095 protocols. 1097 When publishing a record containing an "ech" parameter, the publisher 1098 MUST ensure that all IP addresses of TargetName correspond to servers 1099 that have access to the corresponding private key or are 1100 authoritative for the public name. (See Section 7.2.2 of [ECH] for 1101 more details about the public name.) This yields an anonymity set of 1102 cardinality equal to the number of ECH-enabled server domains 1103 supported by a given client-facing server. Thus, even with an 1104 encrypted ClientHello, an attacker who can enumerate the set of ECH- 1105 enabled domains supported by a client-facing server can guess the 1106 correct SNI with probability at least 1/K, where K is the size of 1107 this ECH-enabled server anonymity set. This probability may be 1108 increased via traffic analysis or other mechanisms. 1110 7.4. "ipv4hint" and "ipv6hint" 1112 The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients 1113 MAY use to reach the service. If A and AAAA records for TargetName 1114 are locally available, the client SHOULD ignore these hints. 1115 Otherwise, clients SHOULD perform A and/or AAAA queries for 1116 TargetName as in Section 3, and clients SHOULD use the IP address in 1117 those responses for future connections. Clients MAY opt to terminate 1118 any connections using the addresses in hints and instead switch to 1119 the addresses in response to the TargetName query. Failure to use A 1120 and/or AAAA response addresses could negatively impact load balancing 1121 or other geo-aware features and thereby degrade client performance. 1123 The presentation value SHALL be a comma-separated list (Appendix A.1) 1124 of one or more IP addresses of the appropriate family in standard 1125 textual format [RFC5952][RFC4001]. To enable simpler parsing, this 1126 SvcParamValue MUST NOT contain escape sequences. 1128 The wire format for each parameter is a sequence of IP addresses in 1129 network byte order (for the respective address-family). Like an A or 1130 AAAA RRSet, the list of addresses represents an unordered collection, 1131 and clients SHOULD pick addresses to use in a random order. An empty 1132 list of addresses is invalid. 1134 When selecting between IPv4 and IPv6 addresses to use, clients may 1135 use an approach such as Happy Eyeballs [HappyEyeballsV2]. When only 1136 "ipv4hint" is present, NAT64 clients may synthesize IPv6 addresses as 1137 specified in [RFC7050] or ignore the "ipv4hint" key and wait for AAAA 1138 resolution (Section 3). For best performance, server operators 1139 SHOULD include an "ipv6hint" parameter whenever they include an 1140 "ipv4hint" parameter. 1142 These parameters are intended to minimize additional connection 1143 latency when a recursive resolver is not compliant with the 1144 requirements in Section 4, and SHOULD NOT be included if most clients 1145 are using compliant recursive resolvers. When TargetName is the 1146 origin hostname or the owner name (which can be written as "."), 1147 server operators SHOULD NOT include these hints, because they are 1148 unlikely to convey any performance benefit. 1150 7.5. "mandatory" 1152 See Section 8. 1154 8. ServiceMode RR compatibility and mandatory keys 1156 In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the 1157 RR will not function correctly for clients that ignore this 1158 SvcParamKey. Each SVCB protocol mapping SHOULD specify a set of keys 1159 that are "automatically mandatory", i.e. mandatory if they are 1160 present in an RR. The SvcParamKey "mandatory" is used to indicate 1161 any mandatory keys for this RR, in addition to any automatically 1162 mandatory keys that are present. 1164 A ServiceMode RR is considered "compatible" by a client if the client 1165 recognizes all the mandatory keys, and their values indicate that 1166 successful connection establishment is possible. If the SVCB RRSet 1167 contains no compatible RRs, the client will generally act as if the 1168 RRSet is empty. 1170 The presentation value SHALL be a comma-separated list (Appendix A.1) 1171 of one or more valid SvcParamKeys, either by their registered name or 1172 in the unknown-key format (Section 2.1). Keys MAY appear in any 1173 order, but MUST NOT appear more than once. For self-consistency 1174 (Section 2.4.3), listed keys MUST also appear in the SvcParams. 1176 To enable simpler parsing, this SvcParamValue MUST NOT contain escape 1177 sequences. 1179 For example, the following is a valid list of SvcParams: 1181 ech=... key65333=ex1 key65444=ex2 mandatory=key65444,ech 1183 In wire format, the keys are represented by their numeric values in 1184 network byte order, concatenated in strictly increasing numeric 1185 order. 1187 This SvcParamKey is always automatically mandatory, and MUST NOT 1188 appear in its own value-list. Other automatically mandatory keys 1189 SHOULD NOT appear in the list either. (Including them wastes space 1190 and otherwise has no effect.) 1192 9. Using Service Bindings with HTTP 1194 Use of any protocol with SVCB requires a protocol-specific mapping 1195 specification. This section specifies the mapping for the "http" and 1196 "https" URI schemes [HTTP]. 1198 To enable special handling for HTTP use-cases, the HTTPS RR type is 1199 defined as a SVCB-compatible RR type, specific to the "https" and 1200 "http" schemes. Clients MUST NOT perform SVCB queries or accept SVCB 1201 responses for "https" or "http" schemes. 1203 The presentation format of the record is: 1205 Name TTL IN HTTPS SvcPriority TargetName SvcParams 1207 All the SvcParamKeys defined in Section 7 are permitted for use in 1208 HTTPS RRs. The default set of ALPN IDs is the single value 1209 "http/1.1". The "automatically mandatory" keys (Section 8) are 1210 "port" and "no-default-alpn". (As described in Section 8, clients 1211 must either implement these keys or ignore any RR in which they 1212 appear.) Clients that restrict the destination port in "https" URIs 1213 (e.g. using the "bad ports" list from [FETCH]) SHOULD apply the same 1214 restriction to the "port" SvcParam. 1216 The presence of an HTTPS RR for an origin also indicates that clients 1217 should connect securely and use the "https" scheme, as discussed in 1218 Section 9.5. This allows HTTPS RRs to apply to pre-existing "http" 1219 scheme URLs, while ensuring that the client uses a secure and 1220 authenticated connection. 1222 The HTTPS RR parallels the concepts introduced in the HTTP 1223 Alternative Services proposed standard [AltSvc]. Clients and servers 1224 that implement HTTPS RRs are not required to implement Alt-Svc. 1226 9.1. Query names for HTTPS RRs 1228 The HTTPS RR uses Port Prefix Naming (Section 2.3), with one 1229 modification: if the scheme is "https" and the port is 443, then the 1230 client's original QNAME is equal to the service name (i.e. the 1231 origin's hostname), without any prefix labels. 1233 By removing the Attrleaf labels [Attrleaf] used in SVCB, this 1234 construction enables offline DNSSEC signing of wildcard domains, 1235 which are commonly used with HTTP. Using the service name as the 1236 owner name of the HTTPS record, without prefixes, also allows the 1237 targets of existing CNAME chains (e.g. CDN hosts) to start returning 1238 HTTPS RR responses without requiring origin domains to configure and 1239 maintain an additional delegation. 1241 Following of HTTPS AliasMode RRs and CNAME aliases is unchanged from 1242 SVCB. 1244 Clients always convert "http" URLs to "https" before performing an 1245 HTTPS RR query using the process described in Section 9.5, so domain 1246 owners MUST NOT publish HTTPS RRs with a prefix of "_http". 1248 Note that none of these forms alter the HTTPS origin or authority. 1249 For example, clients MUST continue to validate TLS certificate 1250 hostnames based on the origin. 1252 9.2. Comparison with Alt-Svc 1254 Publishing a ServiceMode HTTPS RR in DNS is intended to be similar to 1255 transmitting an Alt-Svc field value over HTTP, and receiving an HTTPS 1256 RR is intended to be similar to receiving that field value over HTTP. 1257 However, there are some differences in the intended client and server 1258 behavior. 1260 9.2.1. ALPN usage 1262 Unlike Alt-Svc Field Values, HTTPS RRs can contain multiple ALPN IDs. 1263 The meaning and use of these IDs is discussed in Section 7.1.2. 1265 9.2.2. Untrusted channel 1267 HTTPS records do not require or provide any assurance of 1268 authenticity. (DNSSEC signing and verification, which would provide 1269 such assurance, are OPTIONAL.) The DNS resolution process is modeled 1270 as an untrusted channel that might be controlled by an attacker, so 1271 Alt-Svc parameters that cannot be safely received in this model MUST 1272 NOT have a corresponding defined SvcParamKey. For example, there is 1273 no SvcParamKey corresponding to the Alt-Svc "persist" parameter, 1274 because this parameter is not safe to accept over an untrusted 1275 channel. 1277 9.2.3. Cache lifetime 1279 There is no SvcParamKey corresponding to the Alt-Svc "ma" (max age) 1280 parameter. Instead, server operators encode the expiration time in 1281 the DNS TTL. 1283 The appropriate TTL value might be different from the "ma" value used 1284 for Alt-Svc, depending on the desired efficiency and agility. Some 1285 DNS caches incorrectly extend the lifetime of DNS records beyond the 1286 stated TTL, so server operators cannot rely on HTTPS RRs expiring on 1287 time. Shortening the TTL to compensate for incorrect caching is NOT 1288 RECOMMENDED, as this practice impairs the performance of correctly 1289 functioning caches and does not guarantee faster expiration from 1290 incorrect caches. Instead, server operators SHOULD maintain 1291 compatibility with expired records until they observe that nearly all 1292 connections have migrated to the new configuration. 1294 9.2.4. Granularity 1296 Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc 1297 Field Value specifically to the client. When using an HTTPS RR, 1298 groups of clients will necessarily receive the same SvcParams. 1299 Therefore, HTTPS RRs are not suitable for uses that require single- 1300 client granularity. 1302 9.3. Interaction with Alt-Svc 1304 Clients that implement support for both Alt-Svc and HTTPS records and 1305 are making a connection based on a cached Alt-Svc response SHOULD 1306 retrieve any HTTPS records for the Alt-Svc alt-authority, and ensure 1307 that their connection attempts are consistent with both the Alt-Svc 1308 parameters and any received HTTPS SvcParams. If present, the HTTPS 1309 record's TargetName and port are used for connection establishment 1310 (as in Section 3). For example, suppose that "https://example.com" 1311 sends an Alt-Svc field value of: 1313 Alt-Svc: h2="alt.example:443", h2="alt2.example:443", h3=":8443" 1315 The client would retrieve the following HTTPS records: 1317 alt.example. IN HTTPS 1 . alpn=h2,h3 ech=... 1318 alt2.example. IN HTTPS 1 alt2b.example. alpn=h3 ech=... 1319 _8443._https.example.com. IN HTTPS 1 alt3.example. ( 1320 port=9443 alpn=h2,h3 ech=... ) 1322 Based on these inputs, the following connection attempts would always 1323 be allowed: 1325 * HTTP/2 to alt.example:443 1327 * HTTP/3 to alt3.example:9443 1329 * Fallback to the client's non-Alt-Svc connection behavior 1331 ECH-capable clients would use ECH when establishing any of these 1332 connections. 1334 The following connection attempts would not be allowed: 1336 * HTTP/3 to alt.example:443 (not consistent with Alt-Svc) 1337 * Any connection to alt2b.example (no ALPN consistent with both the 1338 HTTPS record and Alt-Svc) 1340 * HTTPS over TCP to any port on alt3.example (not consistent with 1341 Alt-Svc) 1343 The following Alt-Svc-only connection attempts would be allowed only 1344 if the client does not support ECH, as they rely on SVCB-optional 1345 fallback behavior that the client will disable if it implements 1346 support for ECH and the "ech" SvcParam is present (Section 10.1): 1348 * HTTP/2 to alt2.example:443 1350 * HTTP/3 to example.com:8443 1352 Origins that publish an "ech" SvcParam in their HTTPS record SHOULD 1353 also publish an HTTPS record with the "ech" SvcParam for every alt- 1354 authority offered in its Alt-Svc Field Values. Otherwise, clients 1355 might reveal the name of the server in an unencrypted ClientHello. 1356 Similar consistency considerations could apply to future 1357 SvcParamKeys, so alt-authorities SHOULD carry the same SvcParams as 1358 the origin unless a deviation is specifically known to be safe. 1360 As noted in Section 2.4 of [AltSvc], clients MAY disallow any Alt-Svc 1361 connection according to their own criteria, e.g. disallowing Alt-Svc 1362 connections that lack ECH support when there is an active ECH- 1363 protected connection for this origin. 1365 9.4. Requiring Server Name Indication 1367 Clients MUST NOT use an HTTPS RR response unless the client supports 1368 TLS Server Name Indication (SNI) and indicates the origin name in the 1369 TLS ClientHello (which might be encrypted). This supports the 1370 conservation of IP addresses. 1372 Note that the TLS SNI (and also the HTTP "Host" or ":authority") will 1373 indicate the origin, not the TargetName. 1375 9.5. HTTP Strict Transport Security 1377 An HTTPS RR directs the client to communicate with this host only 1378 over a secure transport, similar to HTTP Strict Transport Security 1379 [HSTS]. Prior to making an "http" scheme request, the client SHOULD 1380 perform a lookup to determine if any HTTPS RRs exist for that origin. 1381 To do so, the client SHOULD construct a corresponding "https" URL as 1382 follows: 1384 1. Replace the "http" scheme with "https". 1386 2. If the "http" URL explicitly specifies port 80, specify port 443. 1388 3. Do not alter any other aspect of the URL. 1390 This construction is equivalent to Section 8.3 of [HSTS], point 5. 1392 If an HTTPS RR query for this "https" URL returns any AliasMode HTTPS 1393 RRs, or any compatible ServiceMode HTTPS RRs (see Section 8), the 1394 client SHOULD behave as if it has received an HTTP 307 (Temporary 1395 Redirect) status code with this "https" URL in the "Location" field. 1396 (Receipt of an incompatible ServiceMode RR does not trigger the 1397 redirect behavior.) Because HTTPS RRs are received over an often- 1398 insecure channel (DNS), clients MUST NOT place any more trust in this 1399 signal than if they had received a 307 (Temporary Redirect) response 1400 over cleartext HTTP. 1402 Publishing an HTTPS RR has the potential to have unexpected results 1403 or a loss in functionality in cases where the "http" resource neither 1404 redirects to the "https" resource nor references the same underlying 1405 resource. 1407 When an "https" connection fails due to an error in the underlying 1408 secure transport, such as an error in certificate validation, some 1409 clients currently offer a "user recourse" that allows the user to 1410 bypass the security error and connect anyway. When making an "https" 1411 scheme request to an origin with an HTTPS RR, either directly or via 1412 the above redirect, such a client MAY remove the user recourse 1413 option. Origins that publish HTTPS RRs therefore MUST NOT rely on 1414 user recourse for access. For more information, see Section 8.4 and 1415 Section 12.1 of [HSTS]. 1417 9.6. Use of HTTPS RRs in other protocols 1419 All HTTP connections to named origins are eligible to use HTTPS RRs, 1420 even when HTTP is used as part of another protocol or without an 1421 explicit HTTP URL. For example, clients that support HTTPS RRs and 1422 implement the altered WebSocket [WebSocket] opening handshake from 1423 the W3C Fetch specification [FETCH] SHOULD use HTTPS RRs for the 1424 requestURL. 1426 When HTTP is used in a context where URLs or redirects are not 1427 applicable (e.g. connections to an HTTP proxy), clients that find a 1428 corresponding HTTPS RR SHOULD implement a security upgrade behavior 1429 equivalent to the one specified in Section 9.5. 1431 Such protocols MAY define their own SVCB mappings, which MAY be 1432 defined to take precedence over HTTPS RRs. 1434 10. SVCB/HTTPS RR parameter for ECH configuration 1436 The SVCB "ech" parameter is defined for conveying the ECH 1437 configuration of an alternative endpoint. In wire format, the value 1438 of the parameter is an ECHConfigList (Section 4 of [ECH]), including 1439 the redundant length prefix. In presentation format, the value is 1440 the ECHConfigList in Base 64 Encoding (Section 4 of [RFC4648]). Base 1441 64 is used here to simplify integration with TLS server software. To 1442 enable simpler parsing, this SvcParam MUST NOT contain escape 1443 sequences. 1445 When ECH is in use, the TLS ClientHello is divided into an 1446 unencrypted "outer" and an encrypted "inner" ClientHello. The outer 1447 ClientHello is an implementation detail of ECH, and its contents are 1448 controlled by the ECHConfig in accordance with [ECH]. The inner 1449 ClientHello is used for establishing a connection to the service, so 1450 its contents may be influenced by other SVCB parameters. For 1451 example, the requirements on the ALPN protocol identifiers in 1452 Section 7.1 apply only to the inner ClientHello. Similarly, it is 1453 the inner ClientHello whose Server Name Indication identifies the 1454 desired service. 1456 10.1. Client behavior 1458 The SVCB-optional client behavior specified in Section 3 permits 1459 clients to fall back to a direct connection if all SVCB options fail. 1460 This behavior is not suitable for ECH, because fallback would negate 1461 the privacy benefits of ECH. Accordingly, ECH-capable SVCB-optional 1462 clients MUST switch to SVCB-reliant connection establishment if SVCB 1463 resolution succeeded (following Section 3) and all alternative 1464 endpoints have an "ech" key. 1466 As a latency optimization, clients MAY prefetch DNS records that will 1467 only be used in SVCB-optional mode. 1469 10.2. Deployment considerations 1471 An HTTPS RRSet containing some RRs with "ech" and some without is 1472 vulnerable to a downgrade attack. This configuration is NOT 1473 RECOMMENDED. Zone owners who do use such a mixed configuration 1474 SHOULD mark the RRs with "ech" as more preferred (i.e. lower 1475 SvcPriority value) than those without, in order to maximize the 1476 likelihood that ECH will be used in the absence of an active 1477 adversary. 1479 11. Zone Structures 1481 11.1. Structuring zones for flexibility 1483 Each ServiceMode RRSet can only serve a single scheme. The scheme is 1484 indicated by the owner name and the RR type. For the generic SVCB RR 1485 type, this means that each owner name can only be used for a single 1486 scheme. The underscore prefixing requirement (Section 2.3) ensures 1487 that this is true for the initial query, but it is the responsibility 1488 of zone owners to choose names that satisfy this constraint when 1489 using aliases, including CNAME and AliasMode records. 1491 When using the generic SVCB RR type with aliasing, zone owners SHOULD 1492 choose alias target names that indicate the scheme in use (e.g. 1493 foosvc.example.net for foo:// schemes). This will help to avoid 1494 confusion when another scheme needs to be added to the configuration. 1495 When multiple port numbers are in use, it may be helpful to repeat 1496 the prefix labels in the alias target name (e.g. 1497 _1234._foo.svc.example.net). 1499 11.2. Structuring zones for performance 1501 To avoid a delay for clients using a nonconforming recursive 1502 resolver, domain owners SHOULD minimize the use of AliasMode records, 1503 and SHOULD choose TargetName according to a predictable convention 1504 that is known to the client, so that clients can issue A and/or AAAA 1505 queries for TargetName in advance (see Section 5). Unless otherwise 1506 specified, the convention is to set TargetName to the service name 1507 for an initial ServiceMode record, or to "." if it is reached via an 1508 alias. 1510 $ORIGIN example.com. ; Origin 1511 foo 3600 IN CNAME foosvc.example.net. 1512 _8080._foo.foo 3600 IN CNAME foosvc.example.net. 1513 bar 300 IN AAAA 2001:db8::2 1514 _9090._bar.bar 3600 IN SVCB 1 bar key65444=... 1516 $ORIGIN example.net. ; Service provider zone 1517 foosvc 3600 IN SVCB 1 . key65333=... 1518 foosvc 300 IN AAAA 2001:db8::1 1520 Figure 1: foo://foo.example.com:8080 is delegated to 1521 foosvc.example.net, but bar://bar.example.com:9090 is served 1522 locally. 1524 Domain owners SHOULD avoid using a TargetName that is below a DNAME, 1525 as this is likely unnecessary and makes responses slower and larger. 1526 Also, zone structures that require following more than 8 aliases 1527 (counting both AliasMode and CNAME records) are NOT RECOMMENDED. 1529 11.3. Examples 1531 11.3.1. Protocol enhancements 1533 Consider a simple zone of the form: 1535 $ORIGIN simple.example. ; Simple example zone 1536 @ 300 IN A 192.0.2.1 1537 AAAA 2001:db8::1 1539 The domain owner could add this record: 1541 @ 7200 IN HTTPS 1 . alpn=h3 1543 to indicate that https://simple.example supports QUIC in addition to 1544 HTTP/1.1 over TLS over TCP (the implicit default). The record could 1545 also include other information (e.g. non-standard port, ECH 1546 configuration). For https://simple.example:8443, the record would 1547 be: 1549 _8443._https 7200 IN HTTPS 1 . alpn=h3 1551 These records also respectively tell clients to replace the scheme 1552 with "https" when loading http://simple.example or 1553 http://simple.example:8443. 1555 11.3.2. Apex aliasing 1557 Consider a zone that is using CNAME aliasing: 1559 $ORIGIN aliased.example. ; A zone that is using a hosting service 1560 ; Subdomain aliased to a high-performance server pool 1561 www 7200 IN CNAME pool.svc.example. 1562 ; Apex domain on fixed IPs because CNAME is not allowed at the apex 1563 @ 300 IN A 192.0.2.1 1564 IN AAAA 2001:db8::1 1566 With HTTPS RRs, the owner of aliased.example could alias the apex by 1567 adding one additional record: 1569 @ 7200 IN HTTPS 0 pool.svc.example. 1571 With this record in place, HTTPS-RR-aware clients will use the same 1572 server pool for aliased.example and www.aliased.example. (They will 1573 also upgrade "http://aliased.example/..." to "https".) Non-HTTPS-RR- 1574 aware clients will just ignore the new record. 1576 Similar to CNAME, HTTPS RRs have no impact on the origin name. When 1577 connecting, clients will continue to treat the authoritative origins 1578 as "https://www.aliased.example" and "https://aliased.example", 1579 respectively, and will validate TLS server certificates accordingly. 1581 11.3.3. Parameter binding 1583 Suppose that svc.example's primary server pool supports HTTP/3, but 1584 its backup server pool does not. This can be expressed in the 1585 following form: 1587 $ORIGIN svc.example. ; A hosting provider. 1588 pool 7200 IN HTTPS 1 . alpn=h2,h3 ech="123..." 1589 HTTPS 2 backup alpn=h2 ech="abc..." 1590 pool 300 IN A 192.0.2.2 1591 AAAA 2001:db8::2 1592 backup 300 IN A 192.0.2.3 1593 AAAA 2001:db8::3 1595 This configuration is entirely compatible with the "Apex aliasing" 1596 example, whether the client supports HTTPS RRs or not. If the client 1597 does support HTTPS RRs, all connections will be upgraded to HTTPS, 1598 and clients will use HTTP/3 if they can. Parameters are "bound" to 1599 each server pool, so each server pool can have its own protocol, ECH 1600 configuration, etc. 1602 11.3.4. Multi-CDN 1604 The HTTPS RR is intended to support HTTPS services operated by 1605 multiple independent entities, such as different Content Delivery 1606 Networks (CDNs) or different hosting providers. This includes the 1607 case where a service is migrated from one operator to another, as 1608 well as the case where the service is multiplexed between multiple 1609 operators for performance, redundancy, etc. 1611 This example shows such a configuration, with www.customer.example 1612 having different DNS responses to different queries, either over time 1613 or due to logic within the authoritative DNS server: 1615 ; This zone contains/returns different CNAME records 1616 ; at different points-in-time. The RRset for "www" can 1617 ; only ever contain a single CNAME. 1619 ; Sometimes the zone has: 1620 $ORIGIN customer.example. ; A Multi-CDN customer domain 1621 www 900 IN CNAME cdn1.svc1.example. 1623 ; and other times it contains: 1624 $ORIGIN customer.example. 1625 www 900 IN CNAME customer.svc2.example. 1627 ; and yet other times it contains: 1628 $ORIGIN customer.example. 1629 www 900 IN CNAME cdn3.svc3.example. 1631 ; With the following remaining constant and always included: 1632 $ORIGIN customer.example. ; A Multi-CDN customer domain 1633 ; The apex is also aliased to www to match its configuration 1634 @ 7200 IN HTTPS 0 www 1635 ; Non-HTTPS-aware clients use non-CDN IPs 1636 A 203.0.113.82 1637 AAAA 2001:db8:203::2 1639 ; Resolutions following the cdn1.svc1.example 1640 ; path use these records. 1641 ; This CDN uses a different alternative service for HTTP/3. 1642 $ORIGIN svc1.example. ; domain for CDN 1 1643 cdn1 1800 IN HTTPS 1 h3pool alpn=h3 ech="123..." 1644 HTTPS 2 . alpn=h2 ech="123..." 1645 A 192.0.2.2 1646 AAAA 2001:db8:192::4 1647 h3pool 300 IN A 192.0.2.3 1648 AAAA 2001:db8:192:7::3 1650 ; Resolutions following the customer.svc2.example 1651 ; path use these records. 1652 ; Note that this CDN only supports HTTP/2. 1653 $ORIGIN svc2.example. ; domain operated by CDN 2 1654 customer 300 IN HTTPS 1 . alpn=h2 ech="xyz..." 1655 60 IN A 198.51.100.2 1656 A 198.51.100.3 1657 A 198.51.100.4 1658 AAAA 2001:db8:198::7 1659 AAAA 2001:db8:198::12 1661 ; Resolutions following the cdn3.svc3.example 1662 ; path use these records. 1664 ; Note that this CDN has no HTTPS records 1665 ; and thus no ECH support. 1666 $ORIGIN svc3.example. ; domain operated by CDN 3 1667 cdn3 60 IN A 203.0.113.8 1668 AAAA 2001:db8:113::8 1670 Note that in the above example, the different CDNs have different ECH 1671 configurations and different capabilities, but clients will use HTTPS 1672 RRs as a bound-together unit. 1674 Domain owners should be cautious when using a multi-CDN 1675 configuration, as it introduces a number of complexities highlighted 1676 by this example: 1678 * If CDN 1 supports ECH, and CDN 2 does not, the client is 1679 vulnerable to ECH downgrade by a network adversary who forces 1680 clients to get CDN 2 records. 1682 * Aliasing the apex to its subdomain simplifies the zone file but 1683 likely increases resolution latency, especially when using a non- 1684 HTTPS-aware recursive resolver. An alternative would be to alias 1685 the zone apex directly to a name managed by a CDN. 1687 * The A, AAAA, and HTTPS resolutions are independent lookups, so 1688 resolvers may observe and follow different CNAMEs to different 1689 CDNs. Clients may thus find that the A and AAAA responses do not 1690 correspond to the TargetName in the HTTPS response, and will need 1691 to perform additional queries to retrieve the correct IP 1692 addresses. Including ipv6hint and ipv4hint will reduce the 1693 performance impact of this case. 1695 * If not all CDNs publish HTTPS records, clients will sometimes 1696 receive NODATA for HTTPS queries (as with cdn3.svc3.example 1697 above), and thus no "ech" SvcParam, but could receive A/AAAA 1698 records from a different CDN which does support ECH. Clients will 1699 be unable to use ECH in this case. 1701 11.3.5. Non-HTTP uses 1703 For protocols other than HTTP, the SVCB RR and an Attrleaf label 1704 [Attrleaf] will be used. For example, to reach an example resource 1705 of "baz://api.example.com:8765", the following SVCB record would be 1706 used to alias it to "svc4-baz.example.net." which in-turn could 1707 return AAAA/A records and/or SVCB records in ServiceMode: 1709 _8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net. 1711 HTTPS RRs use similar Attrleaf labels if the origin contains a non- 1712 default port. 1714 12. Interaction with other standards 1716 This standard is intended to reduce connection latency and improve 1717 user privacy. Server operators implementing this standard SHOULD 1718 also implement TLS 1.3 [RFC8446] and OCSP Stapling [RFC6066], both of 1719 which confer substantial performance and privacy benefits when used 1720 in combination with SVCB records. 1722 To realize the greatest privacy benefits, this proposal is intended 1723 for use over a privacy-preserving DNS transport (like DNS over TLS 1724 [DoT] or DNS over HTTPS [DoH]). However, performance improvements, 1725 and some modest privacy improvements, are possible without the use of 1726 those standards. 1728 Any specification for use of SVCB with a protocol MUST have an entry 1729 for its scheme under the SVCB RR type in the IANA DNS Underscore 1730 Global Scoped Entry Registry [Attrleaf]. The scheme MUST have an 1731 entry in the IANA URI Schemes Registry [RFC7595], and MUST have a 1732 defined specification for use with SVCB. 1734 13. Security Considerations 1736 SVCB/HTTPS RRs permit distribution over untrusted channels, and 1737 clients are REQUIRED to verify that the alternative endpoint is 1738 authoritative for the service (similar to Section 2.1 of [AltSvc]). 1739 Therefore, DNSSEC signing and validation are OPTIONAL for publishing 1740 and using SVCB and HTTPS RRs. 1742 Clients MUST ensure that their DNS cache is partitioned for each 1743 local network, or flushed on network changes, to prevent a local 1744 adversary in one network from implanting a forged DNS record that 1745 allows them to track users or hinder their connections after they 1746 leave that network. 1748 An attacker who can prevent SVCB resolution can deny clients any 1749 associated security benefits. A hostile recursive resolver can 1750 always deny service to SVCB queries, but network intermediaries can 1751 often prevent resolution as well, even when the client and recursive 1752 resolver validate DNSSEC and use a secure transport. These downgrade 1753 attacks can prevent the "https" upgrade provided by the HTTPS RR 1754 (Section 9.5), and disable the encryption enabled by the "ech" 1755 SvcParamKey (Section 10). To prevent downgrades, Section 3.1 1756 recommends that clients abandon the connection attempt when such an 1757 attack is detected. 1759 A hostile DNS intermediary might forge AliasMode "." records 1760 (Section 2.5.1) as a way to block clients from accessing particular 1761 services. Such an adversary could already block entire domains by 1762 forging erroneous responses, but this mechanism allows them to target 1763 particular protocols or ports within a domain. Clients that might be 1764 subject to such attacks SHOULD ignore AliasMode "." records. 1766 A hostile DNS intermediary or origin can return SVCB records 1767 indicating any IP address and port number, including IP addresses 1768 inside the local network and port numbers assigned to internal 1769 services. If the attacker can influence the client's payload (e.g. 1770 TLS session ticket contents), and an internal service has a 1771 sufficiently lax parser, it's possible that the attacker could gain 1772 unintended access. (The same concerns apply to SRV records, HTTP 1773 Alt-Svc, and HTTP redirects.) As a mitigation, SVCB mapping 1774 documents SHOULD indicate any port number restrictions that are 1775 appropriate for the supported transports. 1777 14. Privacy Considerations 1779 Standard address queries reveal the user's intent to access a 1780 particular domain. This information is visible to the recursive 1781 resolver, and to many other parties when plaintext DNS transport is 1782 used. SVCB queries, like queries for SRV records and other specific 1783 RR types, additionally reveal the user's intent to use a particular 1784 protocol. This is not normally sensitive information, but it should 1785 be considered when adding SVCB support in a new context. 1787 15. IANA Considerations 1789 15.1. SVCB RRType 1791 This document defines a new DNS RR type, SVCB, whose value 64 has 1792 been allocated by IANA from the "Resource Record (RR) TYPEs" registry 1793 on the "Domain Name System (DNS) Parameters" page: 1795 * Type: SVCB 1797 * Value: 64 1799 * Meaning: General Purpose Service Binding 1801 * Reference: This document 1803 15.2. HTTPS RRType 1805 This document defines a new DNS RR type, "HTTPS", whose value 65 has 1806 been allocated by IANA from the "Resource Record (RR) TYPEs" registry 1807 on the "Domain Name System (DNS) Parameters" page: 1809 * Type: HTTPS 1811 * Value: 65 1813 * Meaning: Service Binding type for use with HTTP 1815 * Reference: This document 1817 15.3. New registry for Service Parameters 1819 IANA is requested to create a new registry, entitled "Service 1820 Parameter Keys (SvcParamKeys)". This registry defines the namespace 1821 for parameters, including string representations and numeric 1822 SvcParamKey values. This registry is shared with other SVCB- 1823 compatible RR types, such as the HTTPS RR. 1825 ACTION: create this registry, on a new page entitled "DNS Service 1826 Bindings (SVCB)" under the "Domain Name System (DNS) Parameters" 1827 category. 1829 15.3.1. Procedure 1831 A registration MUST include the following fields: 1833 * Number: wire format numeric identifier (range 0-65535) 1835 * Name: unique presentation name 1837 * Meaning: a short description 1839 * Format Reference: pointer to specification text 1841 * Change Controller: Person or entity, with contact information if 1842 appropriate. 1844 The characters in the registered Name MUST be lower-case alphanumeric 1845 or "-" (Section 2.1). The name MUST NOT start with "key" or 1846 "invalid". 1848 New entries in this registry are subject to an Expert Review 1849 registration policy ([RFC8126], Section 4.5). The designated expert 1850 MUST ensure that the Format Reference is stable and publicly 1851 available, and that it specifies how to convert the SvcParamValue's 1852 presentation format to wire format. The Format Reference MAY be any 1853 individual's Internet-Draft, or a document from any other source with 1854 similar assurances of stability and availability. An entry MAY 1855 specify a Format Reference of the form "Same as (other key Name)" if 1856 it uses the same presentation and wire formats as an existing key. 1858 This arrangement supports the development of new parameters while 1859 ensuring that zone files can be made interoperable. 1861 15.3.2. Initial contents 1863 The "Service Binding (SVCB) Parameter Registry" shall initially be 1864 populated with the registrations below: 1866 +=============+=================+=============+=========+===========+ 1867 | Number | Name |Meaning |Format |Change | 1868 | | | |Reference|Controller | 1869 +=============+=================+=============+=========+===========+ 1870 | 0 | mandatory |Mandatory |(This |IETF | 1871 | | |keys in this |document)| | 1872 | | |RR |Section 8| | 1873 +-------------+-----------------+-------------+---------+-----------+ 1874 | 1 | alpn |Additional |(This |IETF | 1875 | | |supported |document)| | 1876 | | |protocols |Section | | 1877 | | | |7.1 | | 1878 +-------------+-----------------+-------------+---------+-----------+ 1879 | 2 | no-default-alpn |No support |(This |IETF | 1880 | | |for default |document)| | 1881 | | |protocol |Section | | 1882 | | | |7.1 | | 1883 +-------------+-----------------+-------------+---------+-----------+ 1884 | 3 | port |Port for |(This |IETF | 1885 | | |alternative |document)| | 1886 | | |endpoint |Section | | 1887 | | | |7.2 | | 1888 +-------------+-----------------+-------------+---------+-----------+ 1889 | 4 | ipv4hint |IPv4 address |(This |IETF | 1890 | | |hints |document)| | 1891 | | | |Section | | 1892 | | | |7.4 | | 1893 +-------------+-----------------+-------------+---------+-----------+ 1894 | 5 | ech |Encrypted |(This |IETF | 1895 | | |ClientHello |document)| | 1896 | | |info |Section | | 1897 | | | |7.3 | | 1898 +-------------+-----------------+-------------+---------+-----------+ 1899 | 6 | ipv6hint |IPv6 address |(This |IETF | 1900 | | |hints |document)| | 1901 | | | |Section | | 1902 | | | |7.4 | | 1903 +-------------+-----------------+-------------+---------+-----------+ 1904 | 65280-65534 | N/A |Private Use |(This |IETF | 1905 | | | |document)| | 1906 +-------------+-----------------+-------------+---------+-----------+ 1907 | 65535 | N/A |Reserved |(This |IETF | 1908 | | |("Invalid |document)| | 1909 | | |key") | | | 1910 +-------------+-----------------+-------------+---------+-----------+ 1912 Table 1 1914 15.4. Other registry updates 1916 Per [Attrleaf], please add the following entry to the DNS Underscore 1917 Global Scoped Entry Registry: 1919 +=========+============+=================+=================+ 1920 | RR TYPE | _NODE NAME | Meaning | Reference | 1921 +=========+============+=================+=================+ 1922 | HTTPS | _https | HTTPS SVCB info | (This document) | 1923 +---------+------------+-----------------+-----------------+ 1925 Table 2 1927 16. Acknowledgments and Related Proposals 1929 There have been a wide range of proposed solutions over the years to 1930 the "CNAME at the Zone Apex" challenge proposed. These include 1931 [I-D.bellis-dnsop-http-record], [I-D.ietf-dnsop-aname], and others. 1933 Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thomson, Lucas 1934 Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, David 1935 Benjamin, Mark Andrews, Emily Stark, Eric Orth, Kyle Rose, Craig 1936 Taylor, Dan McArdle, Brian Dickson, Willem Toorop, Pieter Lexis, 1937 Puneet Sood, Olivier Poitrey, Mashooq Muhaimen, Tom Carpay, and many 1938 others for their feedback and suggestions on this draft. 1940 17. References 1942 17.1. Normative References 1944 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1945 "Transport Layer Security (TLS) Application-Layer Protocol 1946 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1947 July 2014, . 1949 [Attrleaf] Crocker, D., "Scoped Interpretation of DNS Resource 1950 Records through "Underscored" Naming of Attribute Leaves", 1951 BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, 1952 . 1954 [DoH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1955 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1956 . 1958 [DoT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1959 and P. Hoffman, "Specification for DNS over Transport 1960 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1961 2016, . 1963 [ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 1964 Encrypted Client Hello", Work in Progress, Internet-Draft, 1965 draft-ietf-tls-esni-14, 13 February 2022, 1966 . 1969 [HappyEyeballsV2] 1970 Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1971 Better Connectivity Using Concurrency", RFC 8305, 1972 DOI 10.17487/RFC8305, December 2017, 1973 . 1975 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 1976 Semantics", Work in Progress, Internet-Draft, draft-ietf- 1977 httpbis-semantics-19, 12 September 2021, 1978 . 1981 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1982 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1983 . 1985 [RFC1035] Mockapetris, P., "Domain names - implementation and 1986 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1987 November 1987, . 1989 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1990 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1991 DOI 10.17487/RFC1928, March 1996, 1992 . 1994 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1995 Requirement Levels", BCP 14, RFC 2119, 1996 DOI 10.17487/RFC2119, March 1997, 1997 . 1999 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 2000 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 2001 . 2003 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 2004 RFC 3225, DOI 10.17487/RFC3225, December 2001, 2005 . 2007 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 2008 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2009 2003, . 2011 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 2012 Schoenwaelder, "Textual Conventions for Internet Network 2013 Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, 2014 . 2016 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 2017 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 2018 . 2020 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2021 Specifications: ABNF", STD 68, RFC 5234, 2022 DOI 10.17487/RFC5234, January 2008, 2023 . 2025 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2026 Address Text Representation", RFC 5952, 2027 DOI 10.17487/RFC5952, August 2010, 2028 . 2030 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 2031 Extensions: Extension Definitions", RFC 6066, 2032 DOI 10.17487/RFC6066, January 2011, 2033 . 2035 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 2036 Beijnum, "DNS64: DNS Extensions for Network Address 2037 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 2038 DOI 10.17487/RFC6147, April 2011, 2039 . 2041 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 2042 the IPv6 Prefix Used for IPv6 Address Synthesis", 2043 RFC 7050, DOI 10.17487/RFC7050, November 2013, 2044 . 2046 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2047 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2048 DOI 10.17487/RFC7231, June 2014, 2049 . 2051 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 2052 and Registration Procedures for URI Schemes", BCP 35, 2053 RFC 7595, DOI 10.17487/RFC7595, June 2015, 2054 . 2056 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 2057 Kumari, "Client Subnet in DNS Queries", RFC 7871, 2058 DOI 10.17487/RFC7871, May 2016, 2059 . 2061 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2062 Writing an IANA Considerations Section in RFCs", BCP 26, 2063 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2064 . 2066 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2067 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2068 May 2017, . 2070 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2071 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2072 . 2074 [WebSocket] 2075 Fette, I. and A. Melnikov, "The WebSocket Protocol", 2076 RFC 6455, DOI 10.17487/RFC6455, December 2011, 2077 . 2079 17.2. Informative References 2081 [AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP 2082 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 2083 April 2016, . 2085 [DNAME] Rose, S. and W. Wijngaards, "DNAME Redirection in the 2086 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 2087 . 2089 [DNSTerm] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 2090 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 2091 January 2019, . 2093 [FETCH] "Fetch Living Standard", May 2020, 2094 . 2096 [HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 2097 Transport Security (HSTS)", RFC 6797, 2098 DOI 10.17487/RFC6797, November 2012, 2099 . 2101 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 2102 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 2103 quic-http-34, 2 February 2021, 2104 . 2107 [I-D.bellis-dnsop-http-record] 2108 Bellis, R., "A DNS Resource Record for HTTP", Work in 2109 Progress, Internet-Draft, draft-bellis-dnsop-http-record- 2110 00, 3 November 2018, 2111 . 2114 [I-D.ietf-dnsop-aname] 2115 Finch, T., Hunt, E., Dijk, P. V., Eden, A., and M. 2116 Mekking, "Address-specific DNS aliases (ANAME)", Work in 2117 Progress, Internet-Draft, draft-ietf-dnsop-aname-04, 8 2118 July 2019, . 2121 [RFC1912] Barr, D., "Common DNS Operational and Configuration 2122 Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996, 2123 . 2125 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 2126 DOI 10.17487/RFC6454, December 2011, 2127 . 2129 [SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2130 specifying the location of services (DNS SRV)", RFC 2782, 2131 DOI 10.17487/RFC2782, February 2000, 2132 . 2134 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2135 Resource Identifier (URI): Generic Syntax", STD 66, 2136 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2137 . 2139 Appendix A. Decoding text in zone files 2141 DNS zone files are capable of representing arbitrary octet sequences 2142 in basic ASCII text, using various delimiters and encodings. The 2143 algorithm for decoding these character-strings is defined in 2144 Section 5.1 of [RFC1035]. Here we summarize the allowed input to 2145 that algorithm, using ABNF: 2147 ; non-special is VCHAR minus DQUOTE, ";", "(", ")", and "\". 2148 non-special = %x21 / %x23-27 / %x2A-3A / %x3C-5B / %x5D-7E 2149 ; non-digit is VCHAR minus DIGIT 2150 non-digit = %x21-2F / %x3A-7E 2151 ; dec-octet is a number 0-255 as a three-digit decimal number. 2152 dec-octet = ( "0" / "1" ) 2DIGIT / 2153 "2" ( ( %x30-34 DIGIT ) / ( "5" %x30-35 ) ) 2154 escaped = "\" ( non-digit / dec-octet ) 2155 contiguous = 1*( non-special / escaped ) 2156 quoted = DQUOTE *( contiguous / ( ["\"] WSP ) ) DQUOTE 2157 char-string = contiguous / quoted 2159 The decoding algorithm allows char-string to represent any *OCTET, 2160 using quoting to group values (e.g., those with internal whitespace), 2161 and escaping to represent each non-printable octet as a single 2162 escaped sequence. In this document, this algorithm is referred to as 2163 "character-string decoding". The algorithm is the same as used by 2164 in RFC 1035, although the output length in this 2165 document is not limited to 255 octets. 2167 A.1. Decoding a comma-separated list 2169 In order to represent lists of items in zone files, this 2170 specification uses comma-separated lists. When the allowed items in 2171 the list cannot contain "," or "\", this is trivial. (For 2172 simplicity, empty items are not allowed.) A value-list parser that 2173 splits on "," and prohibits items containing "\" is sufficient to 2174 comply with all requirements in this document. This corresponds to 2175 the simple-comma-separated syntax: 2177 ; item-allowed is OCTET minus "," and "\". 2178 item-allowed = %x00-2B / %x2D-5B / %x5D-FF 2179 simple-item = 1*item-allowed 2180 simple-comma-separated = [simple-item *("," simple-item)] 2182 For implementations that allow "," and "\" in item values, the 2183 following escaping syntax applies: 2185 item = 1*OCTET 2186 escaped-item = 1*(item-allowed / "\," / "\\") 2187 comma-separated = [escaped-item *("," escaped-item)] 2189 Decoding of value-lists happens after character-string decoding. For 2190 example, consider these char-string SvcParamValues: 2192 "part1,part2,part3\\,part4\\\\" 2193 part1\,\p\a\r\t2\044part3\092,part4\092\\ 2194 These inputs are equivalent: character-string decoding either of them 2195 would produce the same value: 2197 part1,part2,part3\,part4\\ 2199 Applying comma-separated list decoding to this value would produce a 2200 list of three items: 2202 part1 2203 part2 2204 part3,part4\ 2206 Appendix B. HTTP Mapping Summary 2208 This table serves as a non-normative summary of the HTTP mapping for 2209 SVCB (Section 9). Future protocol mappings may provide a similar 2210 summary table. 2212 +==========================+======================+ 2213 +==========================+======================+ 2214 | *Mapped scheme* | "https" | 2215 +--------------------------+----------------------+ 2216 | *Other affected schemes* | "http", "wss", "ws", | 2217 | | (other HTTP-based) | 2218 +--------------------------+----------------------+ 2219 | *RR type* | HTTPS (65) | 2220 +--------------------------+----------------------+ 2221 | *Name prefix* | None for port 443, | 2222 | | else _$PORT._https | 2223 +--------------------------+----------------------+ 2224 | *Automatically Mandatory | port, no-default- | 2225 | Keys* | alpn | 2226 +--------------------------+----------------------+ 2227 | *SvcParam defaults* | alpn: ["http/1.1"] | 2228 +--------------------------+----------------------+ 2229 | *Special behaviors* | HTTP to HTTPS | 2230 | | upgrade | 2231 +--------------------------+----------------------+ 2232 | *Keys that records must | None | 2233 | include* | | 2234 +--------------------------+----------------------+ 2236 Table 3 2238 Appendix C. Comparison with alternatives 2240 The SVCB and HTTPS RR types closely resemble, and are inspired by, 2241 some existing record types and proposals. A complaint with all of 2242 the alternatives is that web clients have seemed unenthusiastic about 2243 implementing them. The hope here is that by providing an extensible 2244 solution that solves multiple problems we will overcome the inertia 2245 and have a path to achieve client implementation. 2247 C.1. Differences from the SRV RR type 2249 An SRV record [SRV] can perform a similar function to the SVCB 2250 record, informing a client to look in a different location for a 2251 service. However, there are several differences: 2253 * SRV records are typically mandatory, whereas SVCB is intended to 2254 be optional when used with pre-existing protocols. 2256 * SRV records cannot instruct the client to switch or upgrade 2257 protocols, whereas SVCB can signal such an upgrade (e.g. to 2258 HTTP/2). 2260 * SRV records are not extensible, whereas SVCB and HTTPS RRs can be 2261 extended with new parameters. 2263 * SRV records specify a "weight" for unbalanced randomized load- 2264 balancing. SVCB only supports balanced randomized load-balancing, 2265 although weights could be added via a future SvcParam. 2267 C.2. Differences from the proposed HTTP record 2269 Unlike [I-D.bellis-dnsop-http-record], this approach is extensible to 2270 cover Alt-Svc and Encrypted ClientHello use-cases. Like that 2271 proposal, this addresses the zone apex CNAME challenge. 2273 Like that proposal, it remains necessary to continue to include 2274 address records at the zone apex for legacy clients. 2276 C.3. Differences from the proposed ANAME record 2278 Unlike [I-D.ietf-dnsop-aname], this approach is extensible to cover 2279 Alt-Svc and ECH use-cases. This approach also does not require any 2280 changes or special handling on either authoritative or primary 2281 servers, beyond optionally returning in-bailiwick additional records. 2283 Like that proposal, this addresses the zone apex CNAME challenge for 2284 clients that implement this. 2286 However, with this SVCB proposal, it remains necessary to continue to 2287 include address records at the zone apex for legacy clients. If 2288 deployment of this standard is successful, the number of legacy 2289 clients will fall over time. As the number of legacy clients 2290 declines, the operational effort required to serve these users 2291 without the benefit of SVCB indirection should fall. Server 2292 operators can easily observe how much traffic reaches this legacy 2293 endpoint, and may remove the apex's address records if the observed 2294 legacy traffic has fallen to negligible levels. 2296 C.4. Comparison with separate RR types for AliasMode and ServiceMode 2298 Abstractly, functions of AliasMode and ServiceMode are independent, 2299 so it might be tempting to specify them as separate RR types. 2300 However, this would result in a serious performance impairment, 2301 because clients cannot rely on their recursive resolver to follow 2302 SVCB aliases (unlike CNAME). Thus, clients would have to issue 2303 queries for both RR types in parallel, potentially at each step of 2304 the alias chain. Recursive resolvers that implement the 2305 specification would, upon receipt of a ServiceMode query, emit both a 2306 ServiceMode and an AliasMode query to the authoritative. Thus, 2307 splitting the RR type would double, or in some cases triple, the load 2308 on clients and servers, and would not reduce implementation 2309 complexity. 2311 Appendix D. Test vectors 2313 These test vectors only contain the RDATA portion of SVCB/HTTPS 2314 records in presentation format, generic format ([RFC3597]) and wire 2315 format. The wire format uses hexadecimal (\xNN) for each non-ascii 2316 byte. As the wireformat is long, it is broken into several lines. 2318 D.1. AliasMode 2320 example.com. HTTPS 0 foo.example.com. 2322 \# 19 ( 2323 00 00 ; priority 2324 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2325 ) 2327 \x00\x00 # priority 2328 \x03foo\x07example\x03com\x00 # target 2330 Figure 2: AliasMode 2332 D.2. ServiceMode 2333 example.com. SVCB 1 . 2335 \# 3 ( 2336 00 01 ; priority 2337 00 ; target (root label) 2338 ) 2340 \x00\x01 # priority 2341 \x00 # target, root label 2343 Figure 3: TargetName is "." 2345 example.com. SVCB 16 foo.example.com. port=53 2347 \# 25 ( 2348 00 10 ; priority 2349 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2350 00 03 ; key 3 2351 00 02 ; length 2 2352 00 35 ; value 2353 ) 2355 \x00\x10 # priority 2356 \x03foo\x07example\x03com\x00 # target 2357 \x00\x03 # key 3 2358 \x00\x02 # length: 2 bytes 2359 \x00\x35 # value 2361 Figure 4: Specifies a port 2363 example.com. SVCB 1 foo.example.com. key667=hello 2365 \# 28 ( 2366 00 01 ; priority 2367 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2368 02 9b ; key 667 2369 00 05 ; length 5 2370 68 65 6c 6c 6f ; value 2371 ) 2373 \x00\x01 # priority 2374 \x03foo\x07example\x03com\x00 # target 2375 \x02\x9b # key 667 2376 \x00\x05 # length 5 2377 hello # value 2379 Figure 5: A generic key and unquoted value 2381 example.com. SVCB 1 foo.example.com. key667="hello\210qoo" 2383 \# 32 ( 2384 00 01 ; priority 2385 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2386 02 9b ; key 667 2387 00 09 ; length 9 2388 68 65 6c 6c 6f d2 71 6f 6f ; value 2389 ) 2391 \x00\x01 # priority 2392 \x03foo\x07example\x03com\x00 # target 2393 \x02\x9b # key 667 2394 \x00\x09 # length 9 2395 hello\xd2qoo # value 2397 Figure 6: A generic key and quoted value with a decimal escape 2399 example.com. SVCB 1 foo.example.com. ( 2400 ipv6hint="2001:db8::1,2001:db8::53:1" 2401 ) 2403 \# 55 ( 2404 00 01 ; priority 2405 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2406 00 06 ; key 6 2407 00 20 ; length 32 2408 20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01 ; first address 2409 20 01 0d b8 00 00 00 00 00 00 00 00 00 53 00 01 ; second address 2410 ) 2412 \x00\x01 # priority 2413 \x03foo\x07example\x03com\x00 # target 2414 \x00\x06 # key 6 2415 \x00\x20 # length 32 2416 \x20\x01\x0d\xb8\x00\x00\x00\x00 2417 \x00\x00\x00\x00\x00\x00\x00\x01 # first address 2418 \x20\x01\x0d\xb8\x00\x00\x00\x00 2419 \x00\x00\x00\x00\x00\x53\x00\x01 # second address 2421 Figure 7: Two quoted IPv6 hints 2423 example.com. SVCB 1 example.com. ipv6hint="2001:db8:122:344::192.0.2.33" 2425 \# 35 ( 2426 00 01 ; priority 2427 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2428 00 06 ; key 6 2429 00 10 ; length 16 2430 20 01 0d b8 01 22 03 44 00 00 00 00 c0 00 02 21 ; address 2431 ) 2433 \x00\x01 # priority 2434 \x07example\x03com\x00 # target 2435 \x00\x06 # key 6 2436 \x00\x10 # length 16 2437 \x20\x01\x0d\xb8\x01\x22\x03\x44 2438 \x00\x00\x00\x00\xc0\x00\x02\x21 # address 2440 Figure 8: An IPv6 hint using the embedded IPv4 syntax 2442 example.com. SVCB 16 foo.example.org. ( 2443 alpn=h2,h3-19 mandatory=ipv4hint,alpn 2444 ipv4hint=192.0.2.1 2445 ) 2447 \# 48 ( 2448 00 10 ; priority 2449 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target 2450 00 00 ; key 0 2451 00 04 ; param length 4 2452 00 01 ; value: key 1 2453 00 04 ; value: key 4 2454 00 01 ; key 1 2455 00 09 ; param length 9 2456 02 ; alpn length 2 2457 68 32 ; alpn value 2458 05 ; alpn length 5 2459 68 33 2d 31 39 ; alpn value 2460 00 04 ; key 4 2461 00 04 ; param length 4 2462 c0 00 02 01 ; param value 2463 ) 2465 \x00\x10 # priority 2466 \x03foo\x07example\x03org\x00 # target 2467 \x00\x00 # key 0 2468 \x00\x04 # param length 4 2469 \x00\x01 # value: key 1 2470 \x00\x04 # value: key 4 2471 \x00\x01 # key 1 2472 \x00\x09 # param length 9 2473 \x02 # alpn length 2 2474 h2 # alpn value 2475 \x05 # alpn length 5 2476 h3-19 # alpn value 2477 \x00\x04 # key 4 2478 \x00\x04 # param length 4 2479 \xc0\x00\x02\x01 # param value 2481 Figure 9: SvcParamKey ordering is arbitrary in presentation 2482 format but sorted in wire format 2484 example.com. SVCB 16 foo.example.org. alpn="f\\\\oo\\,bar,h2" 2485 example.com. SVCB 16 foo.example.org. alpn=f\\\092oo\092,bar,h2 2487 \# 35 ( 2488 00 10 ; priority 2489 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target 2490 00 01 ; key 1 2491 00 0c ; param length 12 2492 08 ; alpn length 8 2493 66 5c 6f 6f 2c 62 61 72 ; alpn value 2494 02 ; alpn length 2 2495 68 32 ; alpn value 2496 ) 2498 \x00\x10 # priority 2499 \x03foo\x07example\x03org\x00 # target 2500 \x00\x01 # key 1 2501 \x00\x0c # param length 12 2502 \x08 # alpn length 8 2503 f\oo,bar # alpn value 2504 \x02 # alpn length 2 2505 h2 # alpn value 2507 Figure 10: An alpn value with an escaped comma and an escaped 2508 backslash in two presentation formats 2510 D.3. Failure cases 2512 This subsection contains test vectors which are not compliant with 2513 this document. The various reasons for non-compliance are explained 2514 with each example. 2516 example.com. SVCB 1 foo.example.com. ( 2517 key123=abc key123=def 2518 ) 2520 Figure 11: Multiple instances of the same SvcParamKey 2522 example.com. SVCB 1 foo.example.com. mandatory 2523 example.com. SVCB 1 foo.example.com. alpn 2524 example.com. SVCB 1 foo.example.com. port 2525 example.com. SVCB 1 foo.example.com. ipv4hint 2526 example.com. SVCB 1 foo.example.com. ipv6hint 2528 Figure 12: Missing SvcParamValues that must be nonempty 2530 example.com. SVCB 1 foo.example.com. no-default-alpn=abc 2531 Figure 13: The "no-default-alpn" SvcParamKey value must be empty 2533 example.com. SVCB 1 foo.example.com. mandatory=key123 2535 Figure 14: A mandatory SvcParam is missing 2537 example.com. SVCB 1 foo.example.com. mandatory=mandatory 2539 Figure 15: The "mandatory" SvcParamKey must not be included in 2540 the mandatory list 2542 example.com. SVCB 1 foo.example.com. ( 2543 mandatory=key123,key123 key123=abc 2544 ) 2546 Figure 16: Multiple instances of the same SvcParamKey in the 2547 mandatory list 2549 Appendix E. Change history 2551 (This section to be removed by the RFC editor.) 2553 * draft-ietf-dnsop-svcb-https-09 2555 - Extensive adjustments based on IESG reviews, including: 2557 o IANA registry changed to Expert Review policy 2559 o Adjustments to the use of normative language 2561 o Revised and expanded description of HSTS behavior 2563 o Expanded discussion of CNAME handling 2565 o Discussion of SvcParams in AliasMode records 2567 o Restructured ABNF for comma-separated lists 2569 o Additional references and many other minor clarifications 2571 - Other changes include: 2573 o New section on interaction with DNS64 2575 o New text on the interpretation of wildcard owner names 2577 o Adjusted guidance on default ALPN enforcement 2578 o Removed mention of IPv4-mapped IPv6 2580 * draft-ietf-dnsop-svcb-https-08 2582 - Extensive structural and editorial adjustments based on area 2583 reviews, including: 2585 o A new section on SVCB-compatible record types 2587 o Reorganized description of client behavior 2589 o Test vectors are now in titled figures 2591 o Adjusted mapping summary 2593 o Improve description of rules for resolver handling of 2594 invalid SvcParamValues. 2596 - New text on cross-transport fallback (e.g. QUIC vs. TCP) 2598 - Improved explanation of use with domain-oriented transport 2599 proxies 2601 - HTTP terminology adjusted to match draft-ietf-httpbis-semantics 2603 - Improved and corrected IANA instructions 2605 * draft-ietf-dnsop-svcb-https-07 2607 - Editorial improvements following AD review. 2609 * draft-ietf-dnsop-svcb-https-06 2611 - Add requirements for HTTPS origins that also use Alt-Svc 2613 - Remove requirement for comma-escaping related to unusual ALPN 2614 values 2616 - Allow resolvers to reject invalid SvcParamValues, with 2617 additional guidance 2619 * draft-ietf-dnsop-svcb-https-05 2621 - Specify interaction with EDNS Client Subnet and Additional 2622 section caching 2624 - Rename "echconfig" to "ech" 2625 - Add a suite of test vectors (both valid and invalid) and more 2626 examples 2628 - Clarify requirements for resolvers' (non-)use of SvcParams 2630 - Clarify guidance regarding default ALPN values 2632 * draft-ietf-dnsop-svcb-https-04 2634 - Simplify the IANA instructions (pure First Come First Served) 2636 - Recommend against publishing chains of >8 aliases 2638 - Clarify requirements for using SVCB with a transport proxy 2640 - Adjust guidance for Port Prefix Naming 2642 - Minor editorial updates 2644 * draft-ietf-dnsop-svcb-https-03 2646 - Simplified escaping of comma-separated values 2648 - Reorganized client requirements 2650 - Added a warning about port filtering for cross-protocol attacks 2652 - Clarified self-consistency rules for SvcParams 2654 - Added a non-normative mapping summary table for HTTPS 2656 * draft-ietf-dnsop-svcb-https-02 2658 - Added a Privacy Considerations section 2660 - Adjusted resolution fallback description 2662 - Clarified status of SvcParams in AliasMode 2664 - Improved advice on zone structuring and use with Alt-Svc 2666 - Improved examples, including a new Multi-CDN example 2668 - Reorganized text on value-list parsing and SvcPriority 2670 - Improved phrasing and other editorial improvements throughout 2672 * draft-ietf-dnsop-svcb-https-01 2673 - Added a "mandatory" SvcParamKey 2675 - Added the ability to indicate that a service does not exist 2677 - Adjusted resolution and ALPN algorithms 2679 - Major terminology revisions for "origin" and CamelCase names 2681 - Revised ABNF 2683 - Include allocated RR type numbers 2685 - Various corrections, explanations, and recommendations 2687 * draft-ietf-dnsop-svcb-https-00 2689 - Rename HTTPSSVC RR to HTTPS RR 2691 - Rename "an SVCB" to "a SVCB" 2693 - Removed "design considerations and open issues" section and 2694 some other "to be removed" text 2696 * draft-ietf-dnsop-svcb-httpssvc-03 2698 - Revised chain length limit requirements 2700 - Revised IANA registry rules for SvcParamKeys 2702 - Require HTTPS clients to implement SNI 2704 - Update terminology for Encrypted ClientHello 2706 - Clarifications: non-default ports, transport proxies, HSTS 2707 procedure, WebSocket behavior, wire format, IP hints, inner/ 2708 outer ClientHello with ECH 2710 - Various textual and ABNF corrections 2712 * draft-ietf-dnsop-svcb-httpssvc-02 2714 - All changes to Alt-Svc have been removed 2716 - Expanded and reorganized examples 2718 - Priority zero is now the definition of AliasForm 2720 - Repeated SvcParamKeys are no longer allowed 2721 - The "=" sign may be omitted in a key=value pair if the value is 2722 also empty 2724 - In the wire format, SvcParamKeys must be in sorted order 2726 - New text regarding how to handle resolution timeouts 2728 - Expanded description of recursive resolver behavior 2730 - Much more precise description of the intended ALPN behavior 2732 - Match the HSTS specification's language on HTTPS enforcement 2734 - Removed 'esniconfig=""' mechanism and simplified ESNI 2735 connection logic 2737 * draft-ietf-dnsop-svcb-httpssvc-01 2739 - Reduce the emphasis on conversion between HTTPSSVC and Alt-Svc 2741 - Make the "untrusted channel" concept more precise. 2743 - Make SvcFieldPriority = 0 the definition of AliasForm, instead 2744 of a requirement. 2746 * draft-ietf-dnsop-svcb-httpssvc-00 2748 - Document an optimization for optimistic pre-connection. (Chris 2749 Wood) 2751 - Relax IP hint handling requirements. (Eric Rescorla) 2753 * draft-nygren-dnsop-svcb-httpssvc-00 2755 - Generalize to an SVCB record, with special-case handling for 2756 Alt-Svc and HTTPS separated out to dedicated sections. 2758 - Split out a separate HTTPSSVC record for the HTTPS use-case. 2760 - Remove the explicit SvcRecordType=0/1 and instead make the 2761 AliasForm vs ServiceForm be implicit. This was based on 2762 feedback recommending against subtyping RR type. 2764 - Remove one optimization. 2766 * draft-nygren-httpbis-httpssvc-03 2767 - Change redirect type for HSTS-style behavior from 302 to 307 to 2768 reduce ambiguities. 2770 * draft-nygren-httpbis-httpssvc-02 2772 - Remove the redundant length fields from the wire format. 2774 - Define a SvcDomainName of "." for SvcRecordType=1 as being the 2775 HTTPSSVC RRNAME. 2777 - Replace "hq" with "h3". 2779 * draft-nygren-httpbis-httpssvc-01 2781 - Fixes of record name. Replace references to "HTTPSVC" with 2782 "HTTPSSVC". 2784 * draft-nygren-httpbis-httpssvc-00 2786 - Initial version 2788 Authors' Addresses 2790 Ben Schwartz 2791 Google 2792 Email: bemasc@google.com 2794 Mike Bishop 2795 Akamai Technologies 2796 Email: mbishop@evequefou.be 2798 Erik Nygren 2799 Akamai Technologies 2800 Email: erik+ietf@nygren.org