idnits 2.17.1 draft-ietf-dnsop-svcb-https-07.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 are 1 instance 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The "mandatory" SvcParamKey MUST not be included in mandatory list (Section 7). -- The document date (5 August 2021) is 994 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-12 ** 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) -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) Summary: 2 errors (**), 0 flaws (~~), 4 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: 6 February 2022 E. Nygren 6 Akamai Technologies 7 5 August 2021 9 Service binding and parameter specification via the DNS (DNS SVCB and 10 HTTPS RRs) 11 draft-ietf-dnsop-svcb-https-07 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 HTTPS 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 HTTPS and HTTP 23 origins. By providing more information to the client before it 24 attempts to establish a connection, these records offer potential 25 benefits to 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 6 February 2022. 50 Copyright Notice 52 Copyright (c) 2021 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 Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . 10 76 2.4.1. SvcPriority . . . . . . . . . . . . . . . . . . . . . 11 77 2.4.2. AliasMode . . . . . . . . . . . . . . . . . . . . . . 11 78 2.4.3. ServiceMode . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . 13 83 3.1. Handling resolution failures . . . . . . . . . . . . . . 14 84 3.2. Clients using a Proxy . . . . . . . . . . . . . . . . . . 15 85 4. DNS Server Behavior . . . . . . . . . . . . . . . . . . . . . 15 86 4.1. Authoritative servers . . . . . . . . . . . . . . . . . . 15 87 4.2. Recursive resolvers . . . . . . . . . . . . . . . . . . . 16 88 4.3. General requirements . . . . . . . . . . . . . . . . . . 17 89 4.4. EDNS Client Subnet (ECS) . . . . . . . . . . . . . . . . 17 90 5. Performance optimizations . . . . . . . . . . . . . . . . . . 18 91 5.1. Optimistic pre-connection and connection reuse . . . . . 18 92 5.2. Generating and using incomplete responses . . . . . . . . 19 93 6. Initial SvcParamKeys . . . . . . . . . . . . . . . . . . . . 19 94 6.1. "alpn" and "no-default-alpn" . . . . . . . . . . . . . . 19 95 6.2. "port" . . . . . . . . . . . . . . . . . . . . . . . . . 21 96 6.3. "ech" . . . . . . . . . . . . . . . . . . . . . . . . . . 22 97 6.4. "ipv4hint" and "ipv6hint" . . . . . . . . . . . . . . . . 22 99 7. ServiceMode RR compatibility and mandatory keys . . . . . . . 23 100 8. Using SVCB with HTTPS and HTTP . . . . . . . . . . . . . . . 24 101 8.1. Query names for HTTPS RRs . . . . . . . . . . . . . . . . 25 102 8.2. Relationship to Alt-Svc . . . . . . . . . . . . . . . . . 25 103 8.2.1. ALPN usage . . . . . . . . . . . . . . . . . . . . . 25 104 8.2.2. Untrusted channel . . . . . . . . . . . . . . . . . . 25 105 8.2.3. Cache lifetime . . . . . . . . . . . . . . . . . . . 26 106 8.2.4. Granularity . . . . . . . . . . . . . . . . . . . . . 26 107 8.3. Interaction with Alt-Svc . . . . . . . . . . . . . . . . 26 108 8.4. Requiring Server Name Indication . . . . . . . . . . . . 28 109 8.5. HTTP Strict Transport Security . . . . . . . . . . . . . 28 110 8.6. HTTP-based protocols . . . . . . . . . . . . . . . . . . 29 111 9. SVCB/HTTPS RR parameter for ECH configuration . . . . . . . . 29 112 9.1. Client behavior . . . . . . . . . . . . . . . . . . . . . 29 113 9.2. Deployment considerations . . . . . . . . . . . . . . . . 30 114 10. Zone Structures . . . . . . . . . . . . . . . . . . . . . . . 30 115 10.1. Structuring zones for flexibility . . . . . . . . . . . 30 116 10.2. Structuring zones for performance . . . . . . . . . . . 30 117 10.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 31 118 10.3.1. Protocol enhancements . . . . . . . . . . . . . . . 31 119 10.3.2. Apex aliasing . . . . . . . . . . . . . . . . . . . 31 120 10.3.3. Parameter binding . . . . . . . . . . . . . . . . . 32 121 10.3.4. Multi-CDN . . . . . . . . . . . . . . . . . . . . . 32 122 10.3.5. Non-HTTPS uses . . . . . . . . . . . . . . . . . . . 34 123 11. Interaction with other standards . . . . . . . . . . . . . . 35 124 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35 125 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36 126 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 127 14.1. SVCB RRType . . . . . . . . . . . . . . . . . . . . . . 36 128 14.2. HTTPS RRType . . . . . . . . . . . . . . . . . . . . . . 37 129 14.3. New registry for Service Parameters . . . . . . . . . . 37 130 14.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . 37 131 14.3.2. Initial contents . . . . . . . . . . . . . . . . . . 38 132 14.4. Registry updates . . . . . . . . . . . . . . . . . . . . 38 133 15. Acknowledgments and Related Proposals . . . . . . . . . . . . 39 134 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 135 16.1. Normative References . . . . . . . . . . . . . . . . . . 39 136 16.2. Informative References . . . . . . . . . . . . . . . . . 42 137 Appendix A. Decoding text in zone files . . . . . . . . . . . . 43 138 A.1. Decoding a comma-separated list . . . . . . . . . . . . . 44 139 Appendix B. HTTP Mapping Summary . . . . . . . . . . . . . . . . 45 140 Appendix C. Comparison with alternatives . . . . . . . . . . . . 45 141 C.1. Differences from the SRV RR type . . . . . . . . . . . . 46 142 C.2. Differences from the proposed HTTP record . . . . . . . . 46 143 C.3. Differences from the proposed ANAME record . . . . . . . 46 144 C.4. Comparison with separate RR types for AliasMode and 145 ServiceMode . . . . . . . . . . . . . . . . . . . . . . . 47 146 Appendix D. Test vectors . . . . . . . . . . . . . . . . . . . . 47 147 D.1. AliasForm . . . . . . . . . . . . . . . . . . . . . . . . 47 148 D.2. ServiceForm . . . . . . . . . . . . . . . . . . . . . . . 47 149 D.3. Failure cases . . . . . . . . . . . . . . . . . . . . . . 52 150 Appendix E. Change history . . . . . . . . . . . . . . . . . . . 53 151 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 153 1. Introduction 155 The SVCB ("Service Binding") and HTTPS RRs provide clients with 156 complete instructions for access to a service. This information 157 enables improved performance and privacy by avoiding transient 158 connections to a sub-optimal default server, negotiating a preferred 159 protocol, and providing relevant public keys. 161 For example, when clients need to make a connection to fetch 162 resources associated with an HTTPS URI, they currently resolve only A 163 and/or AAAA records for the origin hostname. This is adequate for 164 services that use basic HTTPS (fixed port, no QUIC, no [ECH]), but 165 clients that learn additional information can gain privacy, 166 performance, and operational advantages. It is highly desirable to 167 minimize the number of round-trips and lookups required to learn this 168 additional information. 170 The SVCB and HTTPS RRs also help when the operator of a service 171 wishes to delegate operational control to one or more other domains, 172 e.g. delegating the origin "https://example.com" to a service 173 operator endpoint at "svc.example.net". While this case can 174 sometimes be handled by a CNAME, that does not cover all use-cases. 175 CNAME is also inadequate when the service operator needs to provide a 176 bound collection of consistent configuration parameters through the 177 DNS (such as network location, protocol, and keying information). 179 This document first describes the SVCB RR as a general-purpose 180 resource record that can be applied directly and efficiently to a 181 wide range of services (Section 2). The HTTPS RR is then defined as 182 a special case of SVCB that improves efficiency and convenience for 183 use with HTTPS (Section 8) by avoiding the need for an Attrleaf label 184 [Attrleaf] (Section 8.1). Other protocols with similar needs may 185 follow the pattern of HTTPS and assign their own SVCB-compatible RR 186 types. 188 All behaviors described as applying to the SVCB RR also apply to the 189 HTTPS RR unless explicitly stated otherwise. Section 8 describes 190 additional behaviors specific to the HTTPS RR. Apart from Section 8 191 and introductory examples, much of this document refers only to the 192 SVCB RR, but those references should be taken to apply to SVCB, 193 HTTPS, and any future SVCB-compatible RR types. 195 The SVCB RR has two modes: 1) "AliasMode", which simply delegates 196 operational control for a resource; 2) "ServiceMode", which binds 197 together configuration information for a service endpoint. 198 ServiceMode provides additional key=value parameters within each 199 RDATA set. 201 1.1. Goals of the SVCB RR 203 The goal of the SVCB RR is to allow clients to resolve a single 204 additional DNS RR in a way that: 206 * Provides alternative endpoints that are authoritative for the 207 service, along with parameters associated with each of these 208 endpoints. 210 * Does not assume that all alternative endpoints have the same 211 parameters or capabilities, or are even operated by the same 212 entity. This is important, as DNS does not provide any way to tie 213 together multiple RRs for the same name. For example, if 214 www.example.com is a CNAME alias that switches between one of 215 three CDNs or hosting environments, successive queries for that 216 name may return records that correspond to different environments. 218 * Enables CNAME-like functionality at a zone apex (such as 219 "example.com") for participating protocols, and generally enables 220 delegation of operational authority for an origin within the DNS 221 to an alternate name. 223 Additional goals specific to HTTPS RRs and the HTTPS use-case 224 include: 226 * Connect directly to HTTP3 (QUIC transport) alternative endpoints 227 [HTTP3] 229 * Obtain the Encrypted ClientHello [ECH] keys associated with an 230 alternative endpoint 232 * Support non-default TCP and UDP ports 234 * Enable SRV-like benefits (e.g. apex delegation, as mentioned 235 above) for HTTP(S), where SRV [SRV] has not been widely adopted 237 * Provide an HSTS-like indication [HSTS] signaling that the HTTPS 238 scheme should be used instead of HTTP for this request (see 239 Section 8.5). 241 1.2. Overview of the SVCB RR 243 This subsection briefly describes the SVCB RR in a non-normative 244 manner. (As mentioned above, this all applies equally to the HTTPS 245 RR which shares the same encoding, format, and high-level semantics.) 247 The SVCB RR has two modes: AliasMode, which aliases a name to another 248 name, and ServiceMode, which provides connection information bound to 249 a service endpoint domain. Placing both forms in a single RR type 250 allows clients to fetch the relevant information with a single query. 252 The SVCB RR has two mandatory fields and one optional. The fields 253 are: 255 1. SvcPriority: The priority of this record (relative to others, 256 with lower values preferred). A value of 0 indicates AliasMode. 257 (Described in Section 2.4.1.) 259 2. TargetName: The domain name of either the alias target (for 260 AliasMode) or the alternative endpoint (for ServiceMode). 262 3. SvcParams (optional): A list of key=value pairs describing the 263 alternative endpoint at TargetName (only used in ServiceMode and 264 otherwise ignored). Described in Section 2.1. 266 Cooperating DNS recursive resolvers will perform subsequent record 267 resolution (for SVCB, A, and AAAA records) and return them in the 268 Additional Section of the response. Clients either use responses 269 included in the additional section returned by the recursive resolver 270 or perform necessary SVCB, A, and AAAA record resolutions. DNS 271 authoritative servers can attach in-bailiwick SVCB, A, AAAA, and 272 CNAME records in the Additional Section to responses for a SVCB 273 query. 275 In ServiceMode, the SvcParams of the SVCB RR provide an extensible 276 data model for describing alternative endpoints that are 277 authoritative for the origin, along with parameters associated with 278 each of these alternative endpoints. 280 For the HTTPS use-case, the HTTPS RR enables many of the benefits of 281 Alt-Svc [AltSvc] without waiting for a full HTTP connection 282 initiation (multiple roundtrips) before learning of the preferred 283 alternative, and without necessarily revealing the user's intended 284 destination to all entities along the network path. 286 1.3. Parameter for Encrypted ClientHello 288 This document also defines a parameter for Encrypted ClientHello 289 [ECH] keys. See Section 9. 291 1.4. Terminology 293 Our terminology is based on the common case where the SVCB record is 294 used to access a resource identified by a URI whose "authority" field 295 contains a DNS hostname as the "host". 297 * The "service" is the information source identified by the 298 "authority" and "scheme" of the URI, capable of providing access 299 to the resource. For HTTPS URIs, the "service" corresponds to an 300 HTTPS "origin" [RFC6454]. 302 * The "service name" is the "host" portion of the authority. 304 * The "authority endpoint" is the authority's hostname and a port 305 number implied by the scheme or specified in the URI. 307 * An "alternative endpoint" is a hostname, port number, and other 308 associated instructions to the client on how to reach an instance 309 of service. 311 Additional DNS terminology intends to be consistent with [DNSTerm]. 313 SVCB is a contraction of "service binding". The SVCB RR, HTTPS RR, 314 and future RR types that share SVCB's format and registry are 315 collectively known as SVCB-compatible RR types. 317 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 318 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 319 "OPTIONAL" in this document are to be interpreted as described in BCP 320 14 [RFC2119] [RFC8174] when, and only when, they appear in all 321 capitals, as shown here. 323 2. The SVCB record type 325 The SVCB DNS resource record (RR) type (RR type 64) is used to locate 326 alternative endpoints for a service. 328 The algorithm for resolving SVCB records and associated address 329 records is specified in Section 3. 331 Other SVCB-compatible resource record types can also be defined as- 332 needed. In particular, the HTTPS RR (RR type 65) provides special 333 handling for the case of "https" origins as described in Section 8. 335 SVCB RRs are extensible by a list of SvcParams, which are pairs 336 consisting of a SvcParamKey and a SvcParamValue. Each SvcParamKey 337 has a presentation name and a registered number. Values are in a 338 format specific to the SvcParamKey. Their definition should specify 339 both their presentation format and wire encoding (e.g., domain names, 340 binary data, or numeric values). The initial SvcParamKeys and 341 formats are defined in Section 6. 343 2.1. Zone file presentation format 345 The presentation format of the record is: 347 Name TTL IN SVCB SvcPriority TargetName SvcParams 349 The SVCB record is defined specifically within the Internet ("IN") 350 Class ([RFC1035]). 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 14.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 should contain 1-63 characters from the ranges 361 "a"-"z", "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 367 value = *OCTET 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 "=" is omitted, the "value" is interpreted as empty. 376 Unrecognized keys are represented in presentation format as 377 "keyNNNNN" where NNNNN is the numeric value of the key type without 378 leading zeros. A SvcParam in this form SHALL be parsed as specified 379 above, and the decoded "value" SHALL be used as its wire format 380 encoding. 382 For some SvcParamKeys, the "value" corresponds to a list or set of 383 items. Presentation formats for such keys SHOULD use a comma- 384 separated list (Appendix A.1). 386 SvcParams in presentation format MAY appear in any order, but keys 387 MUST NOT be repeated. 389 2.2. RDATA wire format 391 The RDATA for the SVCB RR consists of: 393 * a 2 octet field for SvcPriority as an integer in network byte 394 order. 396 * the uncompressed, fully-qualified TargetName, represented as a 397 sequence of length-prefixed labels as in Section 3.1 of [RFC1035]. 399 * the SvcParams, consuming the remainder of the record (so smaller 400 than 65535 octets and constrained by the RDATA and DNS message 401 sizes). 403 When the list of SvcParams is non-empty (ServiceMode), it contains a 404 series of SvcParamKey=SvcParamValue pairs, represented as: 406 * a 2 octet field containing the SvcParamKey as an integer in 407 network byte order. (See Section 14.3.2 for the defined values.) 409 * a 2 octet field containing the length of the SvcParamValue as an 410 integer between 0 and 65535 in network byte order (but constrained 411 by the RDATA and DNS message sizes). 413 * an octet string of this length whose contents are in a format 414 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 11). 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 8.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. 454 Note that none of these forms alter the origin or authority for 455 validation purposes. For example, TLS clients MUST continue to 456 validate TLS certificates for the original service name. 458 As an example, the owner of example.com could publish this record: 460 _8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net. 462 to indicate that "foo://api.example.com:8443" is aliased to 463 "svc4.example.net". The owner of example.net, in turn, could publish 464 this record: 466 svc4.example.net. 7200 IN SVCB 3 svc4.example.net. ( 467 alpn="bar" port="8004" ech="..." ) 469 to indicate that these services are served on port number 8004, which 470 supports the protocol "bar" and its associated transport in addition 471 to the default transport protocol for "foo://". 473 (Parentheses are used to ignore a line break ([RFC1035], 474 Section 5.1).) 476 2.4. Interpretation 477 2.4.1. SvcPriority 479 When SvcPriority is 0 the SVCB record is in AliasMode 480 (Section 2.4.2). Otherwise, it is in ServiceMode (Section 2.4.3). 482 Within a SVCB RRSet, all RRs SHOULD have the same Mode. If an RRSet 483 contains a record in AliasMode, the recipient MUST ignore any 484 ServiceMode records in the set. 486 RRSets are explicitly unordered collections, so the SvcPriority field 487 is used to impose an ordering on SVCB RRs. SVCB RRs with a smaller 488 SvcPriority value SHOULD be given preference over RRs with a larger 489 SvcPriority value. 491 When receiving an RRSet containing multiple SVCB records with the 492 same SvcPriority value, clients SHOULD apply a random shuffle within 493 a priority level to the records before using them, to ensure uniform 494 load-balancing. 496 2.4.2. AliasMode 498 In AliasMode, the SVCB record aliases a service to a TargetName. 499 SVCB RRSets SHOULD only have a single resource record in AliasMode. 500 If multiple are present, clients or recursive resolvers SHOULD pick 501 one at random. 503 The primary purpose of AliasMode is to allow aliasing at the zone 504 apex, where CNAME is not allowed. In AliasMode, the TargetName will 505 be the name of a domain that resolves to SVCB (or other SVCB- 506 compatible record such as HTTPS), AAAA, and/or A records. The 507 TargetName SHOULD NOT be equal to the owner name, as this would 508 result in a loop. 510 In AliasMode, records SHOULD NOT include any SvcParams, and 511 recipients MUST ignore any SvcParams that are present. 513 For example, the operator of foo://example.com:8080 could point 514 requests to a service operating at foosvc.example.net by publishing: 516 _8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net. 518 Using AliasMode maintains a separation of concerns: the owner of 519 foosvc.example.net can add or remove ServiceMode SVCB records without 520 requiring a corresponding change to example.com. Note that if 521 foosvc.example.net promises to always publish a SVCB record, this 522 AliasMode record can be replaced by a CNAME, which would likely 523 improve performance. 525 AliasMode is especially useful for SVCB-compatible RR types that do 526 not require an underscore prefix, such as the HTTPS RR type. For 527 example, the operator of https://example.com could point requests to 528 a server at svc.example.net by publishing this record at the zone 529 apex: 531 example.com. 3600 IN HTTPS 0 svc.example.net. 533 Note that the SVCB record's owner name MAY be the canonical name of a 534 CNAME record, and the TargetName MAY be the owner of a CNAME record. 535 Clients and recursive resolvers MUST follow CNAMEs as normal. 537 To avoid unbounded alias chains, clients and recursive resolvers MUST 538 impose a limit on the total number of SVCB aliases they will follow 539 for each resolution request. This limit MUST NOT be zero, i.e. 540 implementations MUST be able to follow at least one AliasMode record. 541 The exact value of this limit is left to implementations. 543 For compatibility and performance, zone owners SHOULD NOT configure 544 their zones to require following multiple AliasMode records. 546 As legacy clients will not know to use this record, service operators 547 will likely need to retain fallback AAAA and A records alongside this 548 SVCB record, although in a common case the target of the SVCB record 549 might offer better performance, and therefore would be preferable for 550 clients implementing this specification to use. 552 AliasMode records only apply to queries for the specific RR type. 553 For example, a SVCB record cannot alias to an HTTPS record, nor vice- 554 versa. 556 2.4.3. ServiceMode 558 In ServiceMode, the TargetName and SvcParams within each resource 559 record associate an alternative endpoint for the service with its 560 connection parameters. 562 Each protocol scheme that uses SVCB MUST define a protocol mapping 563 that explains how SvcParams are applied for connections of that 564 scheme. Unless specified otherwise by the protocol mapping, clients 565 MUST ignore any SvcParam that they do not recognize. 567 Some SvcParams impose requirements on other SvcParams in the RR. A 568 ServiceMode RR is called "self-consistent" if its SvcParams all 569 comply with each others' requirements. Zone-file implementations 570 SHOULD enforce self-consistency. Clients MUST reject any RR whose 571 recognized SvcParams are not self-consistent, and MAY reject the 572 entire RRSet. 574 2.5. Special handling of "." in TargetName 576 If TargetName has the value "." (represented in the wire format as a 577 zero-length label), special rules apply. 579 2.5.1. AliasMode 581 For AliasMode SVCB RRs, a TargetName of "." indicates that the 582 service is not available or does not exist. This indication is 583 advisory: clients encountering this indication MAY ignore it and 584 attempt to connect without the use of SVCB. 586 2.5.2. ServiceMode 588 For ServiceMode SVCB RRs, if TargetName has the value ".", then the 589 owner name of this record MUST be used as the effective TargetName. 591 For example, in the following example "svc2.example.net" is the 592 effective TargetName: 594 example.com. 7200 IN HTTPS 0 svc.example.net. 595 svc.example.net. 7200 IN CNAME svc2.example.net. 596 svc2.example.net. 7200 IN HTTPS 1 . port=8002 ech="..." 597 svc2.example.net. 300 IN A 192.0.2.2 598 svc2.example.net. 300 IN AAAA 2001:db8::2 600 3. Client behavior 602 "SVCB resolution" is the process of enumerating the priority-ordered 603 endpoints for a service, as performed by the client. SVCB resolution 604 is implemented as follows: 606 1. Let $QNAME be the service name plus appropriate prefixes for the 607 scheme (see Section 2.3). 609 2. Issue a SVCB query for $QNAME. 611 3. If an AliasMode SVCB record is returned for $QNAME (after 612 following CNAMEs as normal), set $QNAME to its TargetName 613 (without additional prefixes) and loop back to step 2, subject to 614 chain length limits and loop detection heuristics (see 615 Section 3.1). 617 4. If one or more "compatible" (Section 7) ServiceMode records are 618 returned, these represent the alternative endpoints. 620 5. Otherwise, SVCB resolution has failed, and the list of known 621 endpoints is empty. 623 This procedure does not rely on any recursive or authoritative DNS 624 server to comply with this specification or have any awareness of 625 SVCB. 627 Once SVCB resolution has concluded, the client proceeds with 628 connection establishment. Clients SHOULD try higher-priority 629 alternatives first, with fallback to lower-priority alternatives. 630 Clients issue AAAA and/or A queries for the selected TargetName, and 631 MAY choose between them using an approach such as Happy Eyeballs 632 [HappyEyeballsV2]. 634 A client is called "SVCB-optional" if it can connect without the use 635 of ServiceMode records, and "SVCB-reliant" otherwise. Clients for 636 pre-existing protocols (e.g. HTTPS) SHALL implement SVCB-optional 637 behavior (except as noted in Section 3.1 and Section 9.1). 639 SVCB-optional clients SHOULD issue in parallel any other DNS queries 640 that might be needed for connection establishment. SVCB-optional 641 clients SHALL append an alternative endpoint consisting of the final 642 value of $QNAME, the authority endpoint's port number, and no 643 SvcParams, to the list of alternative endpoints, which is attempted 644 before falling back to non-SVCB connection modes. This ensures that 645 SVCB-optional clients will make use of an AliasMode record whose 646 TargetName has A and/or AAAA records but no SVCB records. 648 Some important optimizations are discussed in Section 5 to avoid 649 additional latency in comparison to ordinary AAAA/A lookups. 651 3.1. Handling resolution failures 653 If SVCB resolution fails due to a SERVFAIL error, transport error, or 654 timeout, and DNS exchanges between the client and the recursive 655 resolver are cryptographically protected (e.g. using TLS [DoT] or 656 HTTPS [DoH]), a SVCB-optional client SHOULD abandon the connection 657 attempt like a SVCB-reliant client would. Otherwise, an active 658 attacker could mount a downgrade attack by denying the user access to 659 the SvcParams. 661 A SERVFAIL error can occur if the domain is DNSSEC-signed, the 662 recursive resolver is DNSSEC-validating, and the attacker is between 663 the recursive resolver and the authoritative DNS server. A transport 664 error or timeout can occur if an active attacker between the client 665 and the recursive resolver is selectively dropping SVCB queries or 666 responses, based on their size or other observable patterns. 668 Similarly, if the client enforces DNSSEC validation on A/AAAA 669 responses, it SHOULD terminate the connection if a SVCB response 670 fails to validate. 672 If the client is unable to complete SVCB resolution due to its chain 673 length limit, the client SHOULD fall back to the authority endpoint, 674 as if the origin's SVCB record did not exist. 676 3.2. Clients using a Proxy 678 Clients using a domain-oriented transport proxy like HTTP CONNECT 679 ([RFC7231], Section 4.3.6) or SOCKS5 ([RFC1928]) have the option to 680 use named destinations, in which case the client does not perform any 681 A or AAAA queries for destination domains. If the client is using 682 named destinations with a proxy that does not provide SVCB query 683 capability (e.g. through an affiliated DNS resolver), the client 684 would have to perform SVCB resolution separately, likely disclosing 685 the destinations to additional parties. Clients that support such 686 proxies SHOULD arrange for a separate SVCB resolution procedure with 687 appropriate privacy properties, or disable SVCB resolution entirely 688 if SVCB-optional. 690 If the client does use SVCB and named destinations, the client SHOULD 691 follow the standard SVCB resolution process, selecting the smallest- 692 SvcPriority option that is compatible with the client and the proxy. 693 When connecting using a SVCB record, clients MUST provide the final 694 TargetName and port to the proxy, which will perform any required A 695 and AAAA lookups. 697 Providing the proxy with the final TargetName has several benefits: 699 * It allows the client to use the SvcParams, if present, which is 700 only usable with a specific TargetName. The SvcParams may include 701 information that enhances performance (e.g. alpn) and privacy 702 (e.g. ech). 704 * It allows the service to delegate the apex domain. 706 * It allows the proxy to select between IPv4 and IPv6 addresses for 707 the server according to its configuration, and receive addresses 708 based on its network geolocation. 710 4. DNS Server Behavior 712 4.1. Authoritative servers 714 When replying to a SVCB query, authoritative DNS servers SHOULD 715 return A, AAAA, and SVCB records in the Additional Section for any 716 TargetNames that are in the zone. If the zone is signed, the server 717 SHOULD also include positive or negative DNSSEC responses for these 718 records in the Additional section. 720 See Section 4.4 for exceptions. 722 4.2. Recursive resolvers 724 Recursive resolvers that are aware of SVCB SHOULD help the client to 725 execute the procedure in Section 3 with minimum overall latency, by 726 incorporating additional useful information into the response. For 727 the initial SVCB record query, this is just the normal response 728 construction process (i.e. unknown RR type resolution under 729 [RFC3597]). For followup resolutions performed during this 730 procedure, we define incorporation as adding all useful RRs from the 731 response to the Additional section without altering the response 732 code. 734 Upon receiving a SVCB query, recursive resolvers SHOULD start with 735 the standard resolution procedure, and then follow this procedure to 736 construct the full response to the stub resolver: 738 1. Incorporate the results of SVCB resolution. If the chain length 739 limit has been reached, terminate successfully (i.e. a NOERROR 740 response). 742 2. If any of the resolved SVCB records are in AliasMode, choose one 743 of them at random, and resolve SVCB, A, and AAAA records for its 744 TargetName. 746 * If any SVCB records are resolved, go to step 1. 748 * Otherwise, incorporate the results of A and AAAA resolution, 749 and terminate. 751 3. All the resolved SVCB records are in ServiceMode. Resolve A and 752 AAAA queries for each TargetName (or for the owner name if 753 TargetName is "."), incorporate all the results, and terminate. 755 In this procedure, "resolve" means the resolver's ordinary recursive 756 resolution procedure, as if processing a query for that RRSet. This 757 includes following any aliases that the resolver would ordinarily 758 follow (e.g. CNAME, DNAME [DNAME]). 760 See Section 2.4.2 for additional safeguards for recursive resolvers 761 to implement to mitigate loops. 763 See Section 5.2 for possible optimizations of this procedure. 765 4.3. General requirements 767 Recursive resolvers MUST be able to convey SVCB records with 768 unrecognized SvcParamKeys, and MAY treat the entire SvcParams portion 769 of the record as opaque. No part of this specification requires 770 recursive resolvers to alter their behavior based on its contents, 771 even if the contents are invalid. Recursive resolvers MAY validate 772 the values of recognized SvcParamKeys and reject records containing 773 values which are invalid according to the SvcParam specification. 774 For complex value types whose interpretation might differ between 775 implementations or have additional future allowed values added (e.g. 776 URIs or "alpn"), resolvers SHOULD limit validation to specified 777 constraints. 779 When responding to a query that includes the DNSSEC OK bit 780 ([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers 781 MUST accompany each RRSet in the Additional section with the same 782 DNSSEC-related records that they would send when providing that RRSet 783 as an Answer (e.g. RRSIG, NSEC, NSEC3). 785 According to Section 5.4.1 of [RFC2181], "Unauthenticated RRs 786 received and cached from ... the additional data section ... should 787 not be cached in such a way that they would ever be returned as 788 answers to a received query. They may be returned as additional 789 information where appropriate.". Recursive resolvers therefore MAY 790 cache records from the Additional section for use in populating 791 Additional section responses, and MAY cache them for general use if 792 they are authenticated by DNSSEC. 794 4.4. EDNS Client Subnet (ECS) 796 The EDNS Client Subnet option (ECS, [RFC7871]) allows recursive 797 resolvers to request IP addresses that are suitable for a particular 798 client IP range. SVCB records may contain IP addresses (in ipv*hint 799 SvcParams), or direct users to a subnet-specific TargetName, so 800 recursive resolvers SHOULD include the same ECS option in SVCB 801 queries as in A/AAAA queries. 803 According to Section 7.3.1 of [RFC7871], "Any records from [the 804 Additional section] MUST NOT be tied to a network". Accordingly, 805 when processing a response whose QTYPE is SVCB-compatible, resolvers 806 SHOULD treat any records in the Additional section as having SOURCE 807 PREFIX-LENGTH zero and SCOPE PREFIX-LENGTH as specified in the ECS 808 option. Authoritative servers MUST omit such records if they are not 809 suitable for use by any stub resolvers that set SOURCE PREFIX-LENGTH 810 to zero. This will cause the resolver to perform a followup query 811 that can receive properly tailored ECS. (This is similar to the 812 usage of CNAME with ECS discussed in [RFC7871], Section 7.2.1.) 813 Authoritative servers that omit Additional records can avoid the 814 added latency of a followup query by following the advice in 815 Section 10.2. 817 5. Performance optimizations 819 For optimal performance (i.e. minimum connection setup time), clients 820 SHOULD implement a client-side DNS cache. Responses in the 821 Additional section of a SVCB response SHOULD be placed in cache 822 before performing any followup queries. With this behavior, and 823 conforming DNS servers, using SVCB does not add network latency to 824 connection setup. 826 To improve performance when using a non-conforming recursive 827 resolver, clients SHOULD issue speculative A and/or AAAA queries in 828 parallel with each SVCB query, based on a predicted value of 829 TargetName (see Section 10.2). 831 After a ServiceMode RRSet is received, clients MAY try more than one 832 option in parallel, and MAY prefetch A and AAAA records for multiple 833 TargetNames. 835 5.1. Optimistic pre-connection and connection reuse 837 If an address response arrives before the corresponding SVCB 838 response, the client MAY initiate a connection as if the SVCB query 839 returned NODATA, but MUST NOT transmit any information that could be 840 altered by the SVCB response until it arrives. For example, a TLS 841 ClientHello can be altered by the "ech" value of a SVCB response 842 (Section 6.3). Clients implementing this optimization SHOULD wait 843 for 50 milliseconds before starting optimistic pre-connection, as per 844 the guidance in [HappyEyeballsV2]. 846 A SVCB record is consistent with a connection if the client would 847 attempt an equivalent connection when making use of that record. If 848 a SVCB record is consistent with an active or in-progress connection 849 C, the client MAY prefer that record and use C as its connection. 850 For example, suppose the client receives this SVCB RRSet for a 851 protocol that uses TLS over TCP: 853 _1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. ( 854 ech="111..." ipv6hint=2001:db8::1 port=1234 ) 855 SVCB 2 svc2.example.net. ( 856 ech="222..." ipv6hint=2001:db8::2 port=1234 ) 858 If the client has an in-progress TCP connection to 859 "[2001:db8::2]:1234", it MAY proceed with TLS on that connection 860 using "ech="222..."", even though the other record in the RRSet has 861 higher priority. 863 If none of the SVCB records are consistent with any active or in- 864 progress connection, clients proceed with connection establishment as 865 described in Section 3. 867 5.2. Generating and using incomplete responses 869 When following the procedure in Section 4.2, recursive resolvers MAY 870 terminate the procedure early and produce a reply that omits some of 871 the associated RRSets. This is REQUIRED when the chain length limit 872 is reached (Section 4.2 step 1), but might also be appropriate when 873 the maximum response size is reached, or when responding before fully 874 chasing dependencies would improve performance. When omitting 875 certain RRSets, recursive resolvers SHOULD prioritize information for 876 smaller-SvcPriority records. 878 As discussed in Section 3, clients MUST be able to fetch additional 879 information that is required to use a SVCB record, if it is not 880 included in the initial response. As a performance optimization, if 881 some of the SVCB records in the response can be used without 882 requiring additional DNS queries, the client MAY prefer those 883 records, regardless of their priorities. 885 6. Initial SvcParamKeys 887 A few initial SvcParamKeys are defined here. These keys are useful 888 for HTTPS, and most are applicable to other protocols as well. Each 889 new protocol mapping document MUST specify which keys are applicable 890 and safe to use. Protocol mappings MAY alter the interpretation of 891 SvcParamKeys but MUST NOT alter their presentation or wire formats. 893 6.1. "alpn" and "no-default-alpn" 895 The "alpn" and "no-default-alpn" SvcParamKeys together indicate the 896 set of Application Layer Protocol Negotiation (ALPN) protocol 897 identifiers [ALPN] and associated transport protocols supported by 898 this service endpoint. 900 As with Alt-Svc [AltSvc], the ALPN protocol identifier is used to 901 identify the application protocol and associated suite of protocols 902 supported by the endpoint (the "protocol suite"). Clients filter the 903 set of ALPN identifiers to match the protocol suites they support, 904 and this informs the underlying transport protocol used (such as 905 QUIC-over-UDP or TLS-over-TCP). 907 ALPNs are identified by their registered "Identification Sequence" 908 ("alpn-id"), which is a sequence of 1-255 octets. 910 alpn-id = 1*255OCTET 912 The presentation "value" SHALL be a comma-separated list 913 (Appendix A.1) of one or more "alpn-id"s. Zone file implementations 914 MAY disallow the "," and "\" characters instead of implementing the 915 "value-list" escaping procedure, relying on the opaque key format 916 (e.g. "key1=\002h2") in the event that these characters are needed. 918 The wire format value for "alpn" consists of at least one "alpn-id" 919 prefixed by its length as a single octet, and these length-value 920 pairs are concatenated to form the SvcParamValue. These pairs MUST 921 exactly fill the SvcParamValue; otherwise, the SvcParamValue is 922 malformed. 924 For "no-default-alpn", the presentation and wire format values MUST 925 be empty. When "no-default-alpn" is specified in an RR, "alpn" must 926 also be specified in order for the RR to be "self-consistent" 927 (Section 2.4.3). 929 Each scheme that uses this SvcParamKey defines a "default set" of 930 ALPNs that are supported by nearly all clients and servers, which MAY 931 be empty. To determine the set of protocol suites supported by an 932 endpoint (the "SVCB ALPN set"), the client adds the default set to 933 the list of "alpn-id"s unless the "no-default-alpn" SvcParamKey is 934 present. The presence of an ALPN protocol in the SVCB ALPN set 935 indicates that this service endpoint, described by TargetName and the 936 other parameters (e.g. "port") offers service with the protocol suite 937 associated with this ALPN protocol. 939 ALPN protocol names that do not uniquely identify a protocol suite 940 (e.g. an Identification Sequence that can be used with both TLS and 941 DTLS) are not compatible with this SvcParamKey and MUST NOT be 942 included in the SVCB ALPN set. 944 To establish a connection to the endpoint, clients MUST 946 1. Let SVCB-ALPN-Intersection be the set of protocols in the SVCB 947 ALPN set that the client supports. 949 2. Let Intersection-Transports be the set of transports (e.g. TLS, 950 DTLS, QUIC) implied by the protocols in SVCB-ALPN-Intersection. 952 3. For each transport in Intersection-Transports, construct a 953 ProtocolNameList containing the Identification Sequences of all 954 the client's supported ALPN protocols for that transport, without 955 regard to the SVCB ALPN set. 957 For example, if the SVCB ALPN set is ["http/1.1", "h3"], and the 958 client supports HTTP/1.1, HTTP/2, and HTTP/3, the client could 959 attempt to connect using TLS over TCP with a ProtocolNameList of 960 ["http/1.1", "h2"], and could also attempt a connection using QUIC, 961 with a ProtocolNameList of ["h3"]. 963 Once the client has constructed a ClientHello, protocol negotiation 964 in that handshake proceeds as specified in [ALPN], without regard to 965 the SVCB ALPN set. 967 With this procedure in place, an attacker who can modify DNS and 968 network traffic can prevent a successful transport connection, but 969 cannot otherwise interfere with ALPN protocol selection. This 970 procedure also ensures that each ProtocolNameList includes at least 971 one protocol from the SVCB ALPN set. 973 Clients SHOULD NOT attempt connection to a service endpoint whose 974 SVCB ALPN set does not contain any supported protocols. To ensure 975 consistency of behavior, clients MAY reject the entire SVCB RRSet and 976 fall back to basic connection establishment if all of the RRs 977 indicate "no-default-alpn", even if connection could have succeeded 978 using a non-default alpn. 980 For compatibility with clients that require default transports, zone 981 operators SHOULD ensure that at least one RR in each RRSet supports 982 the default transports. 984 6.2. "port" 986 The "port" SvcParamKey defines the TCP or UDP port that should be 987 used to reach this alternative endpoint. If this key is not present, 988 clients SHALL use the authority endpoint's port number. 990 The presentation "value" of the SvcParamValue is a single decimal 991 integer between 0 and 65535 in ASCII. Any other "value" (e.g. an 992 empty value) is a syntax error. To enable simpler parsing, this 993 SvcParam MUST NOT contain escape sequences. 995 The wire format of the SvcParamValue is the corresponding 2 octet 996 numeric value in network byte order. 998 If a port-restricting firewall is in place between some client and 999 the service endpoint, changing the port number might cause that 1000 client to lose access to the service, so operators should exercise 1001 caution when using this SvcParamKey to specify a non-default port. 1003 6.3. "ech" 1005 The SvcParamKey to enable Encrypted ClientHello (ECH) is "ech". Its 1006 value is defined in Section 9. It is applicable to most TLS-based 1007 protocols. 1009 When publishing a record containing an "ech" parameter, the publisher 1010 MUST ensure that all IP addresses of TargetName correspond to servers 1011 that have access to the corresponding private key or are 1012 authoritative for the public name. (See Section 7.2.2 of [ECH] for 1013 more details about the public name.) This yields an anonymity set of 1014 cardinality equal to the number of ECH-enabled server domains 1015 supported by a given client-facing server. Thus, even with an 1016 encrypted ClientHello, an attacker who can enumerate the set of ECH- 1017 enabled domains supported by a client-facing server can guess the 1018 correct SNI with probability at least 1/K, where K is the size of 1019 this ECH-enabled server anonymity set. This probability may be 1020 increased via traffic analysis or other mechanisms. 1022 6.4. "ipv4hint" and "ipv6hint" 1024 The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients 1025 MAY use to reach the service. If A and AAAA records for TargetName 1026 are locally available, the client SHOULD ignore these hints. 1027 Otherwise, clients SHOULD perform A and/or AAAA queries for 1028 TargetName as in Section 3, and clients SHOULD use the IP address in 1029 those responses for future connections. Clients MAY opt to terminate 1030 any connections using the addresses in hints and instead switch to 1031 the addresses in response to the TargetName query. Failure to use A 1032 and/or AAAA response addresses could negatively impact load balancing 1033 or other geo-aware features and thereby degrade client performance. 1035 The presentation "value" SHALL be a comma-separated list 1036 (Appendix A.1) of one or more IP addresses of the appropriate family 1037 in standard textual format [RFC5952]. To enable simpler parsing, 1038 this SvcParamValue MUST NOT contain escape sequences. 1040 The wire format for each parameter is a sequence of IP addresses in 1041 network byte order. Like an A or AAAA RRSet, the list of addresses 1042 represents an unordered collection, and clients SHOULD pick addresses 1043 to use in a random order. An empty list of addresses is invalid. 1045 When selecting between IPv4 and IPv6 addresses to use, clients may 1046 use an approach such as Happy Eyeballs [HappyEyeballsV2]. When only 1047 "ipv4hint" is present, IPv6-only clients may synthesize IPv6 1048 addresses as specified in [RFC7050] or ignore the "ipv4hint" key and 1049 wait for AAAA resolution (Section 3). Recursive resolvers MUST NOT 1050 perform DNS64 ([RFC6147]) on parameters within a SVCB record. For 1051 best performance, server operators SHOULD include an "ipv6hint" 1052 parameter whenever they include an "ipv4hint" parameter. 1054 These parameters are intended to minimize additional connection 1055 latency when a recursive resolver is not compliant with the 1056 requirements in Section 4, and SHOULD NOT be included if most clients 1057 are using compliant recursive resolvers. When TargetName is the 1058 origin hostname or the owner name (which can be written as "."), 1059 server operators SHOULD NOT include these hints, because they are 1060 unlikely to convey any performance benefit. 1062 7. ServiceMode RR compatibility and mandatory keys 1064 In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the 1065 RR will not function correctly for clients that ignore this 1066 SvcParamKey. Each SVCB protocol mapping SHOULD specify a set of keys 1067 that are "automatically mandatory", i.e. mandatory if they are 1068 present in an RR. The SvcParamKey "mandatory" is used to indicate 1069 any mandatory keys for this RR, in addition to any automatically 1070 mandatory keys that are present. 1072 A ServiceMode RR is considered "compatible" with a client if the 1073 client recognizes all the mandatory keys, and their values indicate 1074 that successful connection establishment is possible. If the SVCB 1075 RRSet contains no compatible RRs, the client will generally act as if 1076 the RRSet is empty. 1078 The presentation "value" SHALL be a comma-separated list 1079 (Appendix A.1) of one or more valid SvcParamKeys, either by their 1080 registered name or in the unknown-key format (Section 2.1). Keys MAY 1081 appear in any order, but MUST NOT appear more than once. For self- 1082 consistency (Section 2.4.3), listed keys MUST also appear in the 1083 SvcParams. 1085 To enable simpler parsing, this SvcParamValue MUST NOT contain escape 1086 sequences. 1088 For example, the following is a valid list of SvcParams: 1090 ech=... key65333=ex1 key65444=ex2 mandatory=key65444,ech 1091 In wire format, the keys are represented by their numeric values in 1092 network byte order, concatenated in ascending order. 1094 This SvcParamKey is always automatically mandatory, and MUST NOT 1095 appear in its own value-list. Other automatically mandatory keys 1096 SHOULD NOT appear in the list either. (Including them wastes space 1097 and otherwise has no effect.) 1099 8. Using SVCB with HTTPS and HTTP 1101 Use of any protocol with SVCB requires a protocol-specific mapping 1102 specification. This section specifies the mapping for HTTPS and 1103 HTTP. 1105 To enable special handling for the HTTPS and HTTP use-cases, the 1106 HTTPS RR type is defined as a SVCB-compatible RR type, specific to 1107 the https and http schemes. Clients MUST NOT perform SVCB queries or 1108 accept SVCB responses for "https" or "http" schemes. 1110 The HTTPS RR wire format and presentation format are identical to 1111 SVCB, and both share the SvcParamKey registry. SVCB semantics apply 1112 equally to HTTPS RRs unless specified otherwise. The presentation 1113 format of the record is: 1115 Name TTL IN HTTPS SvcPriority TargetName SvcParams 1117 As with SVCB, the record is defined specifically within the Internet 1118 ("IN") Class [RFC1035]. 1120 All the SvcParamKeys defined in Section 6 are permitted for use in 1121 HTTPS RRs. The default set of ALPN IDs is the single value 1122 "http/1.1". The "automatically mandatory" keys (Section 7) are 1123 "port" and "no-default-alpn". (As described in Section 7, clients 1124 must either implement these keys or ignore any RR in which they 1125 appear.) Clients that restrict the HTTPS destination port (e.g. 1126 using the "bad ports" list from [FETCH]) SHOULD apply the same 1127 restriction to the "port" SvcParam. 1129 The presence of an HTTPS RR for an origin also indicates that all 1130 HTTP resources are available over HTTPS, as discussed in Section 8.5. 1131 This allows HTTPS RRs to apply to pre-existing "http" scheme URLs, 1132 while ensuring that the client uses a secure and authenticated HTTPS 1133 connection. 1135 The HTTPS RR parallels the concepts introduced in the HTTP 1136 Alternative Services proposed standard [AltSvc]. Clients and servers 1137 that implement HTTPS RRs are not required to implement Alt-Svc. 1139 8.1. Query names for HTTPS RRs 1141 The HTTPS RR uses Port Prefix Naming (Section 2.3), with one 1142 modification: if the scheme is "https" and the port is 443, then the 1143 client's original QNAME is equal to the service name (i.e. the 1144 origin's hostname), without any prefix labels. 1146 By removing the Attrleaf labels [Attrleaf] used in SVCB, this 1147 construction enables offline DNSSEC signing of wildcard domains, 1148 which are commonly used with HTTPS. Reusing the service name also 1149 allows the targets of existing CNAME chains (e.g. CDN hosts) to 1150 start returning HTTPS RR responses without requiring origin domains 1151 to configure and maintain an additional delegation. 1153 Following of HTTPS AliasMode RRs and CNAME aliases is unchanged from 1154 SVCB. 1156 Clients always convert "http" URLs to "https" before performing an 1157 HTTPS RR query using the process described in Section 8.5, so domain 1158 owners MUST NOT publish HTTPS RRs with a prefix of "_http". 1160 Note that none of these forms alter the HTTPS origin or authority. 1161 For example, clients MUST continue to validate TLS certificate 1162 hostnames based on the origin. 1164 8.2. Relationship to Alt-Svc 1166 Publishing a ServiceMode HTTPS RR in DNS is intended to be similar to 1167 transmitting an Alt-Svc field value over HTTPS, and receiving an 1168 HTTPS RR is intended to be similar to receiving that field value over 1169 HTTPS. However, there are some differences in the intended client 1170 and server behavior. 1172 8.2.1. ALPN usage 1174 Unlike Alt-Svc Field Values, HTTPS RRs can contain multiple ALPN IDs, 1175 and clients are encouraged to offer additional ALPNs that they 1176 support. 1178 8.2.2. Untrusted channel 1180 SVCB does not require or provide any assurance of authenticity. 1181 (DNSSEC signing and verification, which would provide such assurance, 1182 are OPTIONAL.) The DNS resolution process is treated as an untrusted 1183 channel that learns only the QNAME, and is prevented from mounting 1184 any attack beyond denial of service. 1186 Alt-Svc parameters that cannot be safely received in this model MUST 1187 NOT have a corresponding defined SvcParamKey. For example, there is 1188 no SvcParamKey corresponding to the Alt-Svc "persist" parameter, 1189 because this parameter is not safe to accept over an untrusted 1190 channel. 1192 8.2.3. Cache lifetime 1194 There is no SvcParamKey corresponding to the Alt-Svc "ma" (max age) 1195 parameter. Instead, server operators encode the expiration time in 1196 the DNS TTL. 1198 The appropriate TTL value might be different from the "ma" value used 1199 for Alt-Svc, depending on the desired efficiency and agility. Some 1200 DNS caches incorrectly extend the lifetime of DNS records beyond the 1201 stated TTL, so server operators cannot rely on HTTPS RRs expiring on 1202 time. Shortening the TTL to compensate for incorrect caching is NOT 1203 RECOMMENDED, as this practice impairs the performance of correctly 1204 functioning caches and does not guarantee faster expiration from 1205 incorrect caches. Instead, server operators SHOULD maintain 1206 compatibility with expired records until they observe that nearly all 1207 connections have migrated to the new configuration. 1209 8.2.4. Granularity 1211 Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc 1212 Field Value specifically to the client. When using an HTTPS RR, 1213 groups of clients will necessarily receive the same SvcParams. 1214 Therefore, HTTPS RRs are not suitable for uses that require single- 1215 client granularity. 1217 8.3. Interaction with Alt-Svc 1219 Clients that implement support for both Alt-Svc and HTTPS records 1220 SHOULD retrieve any HTTPS records for the Alt-Svc alt-authority, and 1221 ensure that their connection attempts are consistent with both the 1222 Alt-Svc parameters and any received HTTPS SvcParams. If present, the 1223 HTTPS record's TargetName and port override the alt-authority. For 1224 example, suppose that "https://example.com" sends an Alt-Svc field 1225 value of: 1227 Alt-Svc: h2="alt.example:443", h2="alt2.example:443", h3=":8443" 1229 The client would retrieve the following HTTPS records: 1231 alt.example. IN HTTPS 1 . alpn=h2,h3 ech=... 1232 alt2.example. IN HTTPS 1 alt2b.example. alpn=h3 ech=... 1233 _8443._https.example.com. IN HTTPS 1 alt3.example. ( 1234 port=9443 alpn=h2,h3 ech=... ) 1236 Based on these inputs, the following connection attempts would always 1237 be allowed: 1239 * HTTPS over TCP to "alt.example:443" (Consistent with both Alt-Svc 1240 and its HTTPS record) 1242 * HTTP/3 to "alt3.example:9443" (Consistent with both Alt-Svc and 1243 its HTTPS record) 1245 * Fallback to the the client's non-Alt-Svc connection behavior 1247 ECH-capable clients would use ECH when establishing any of these 1248 connections. 1250 The following connection attempts would not be allowed: 1252 * HTTP/3 to "alt.example:443" (not consistent with Alt-Svc) 1254 * Any connection to "alt2b.example" (no ALPN consistent with both 1255 the HTTPS record and Alt-Svc) 1257 * HTTPS over TCP to any port on "alt3.example" (not consistent with 1258 Alt-Svc) 1260 The following connection attempts would be allowed only if the client 1261 does not support ECH, as they rely on SVCB-optional fallback behavior 1262 that is disabled when the "ech" SvcParam is present (Section 9.1): 1264 * HTTPS over TCP to "alt2.example:443" (Alt-Svc only) 1266 * HTTP/3 to "example.com:8443" (Alt-Svc only) 1268 Origins that publish an "ech" SvcParam in their HTTPS record SHOULD 1269 also publish an "ech" SvcParam for any alt-authorities. Otherwise, 1270 clients might reveal the name of the server in an unencrypted 1271 ClientHello. Similar consistency considerations could apply to 1272 future SvcParamKeys, so alt-authorities SHOULD carry the same 1273 SvcParams as the origin unless a deviation is specifically known to 1274 be safe. 1276 As noted in Section 2.4 of [AltSvc], clients MAY disallow any Alt-Svc 1277 connection according to their own criteria, e.g. disallowing Alt-Svc 1278 connections that lack ECH support when there is an active ECH- 1279 protected connection for this origin. 1281 8.4. Requiring Server Name Indication 1283 Clients MUST NOT use an HTTPS RR response unless the client supports 1284 TLS Server Name Indication (SNI) and indicates the origin name when 1285 negotiating TLS. This supports the conservation of IP addresses. 1287 Note that the TLS SNI (and also the HTTP "Host" or ":authority") will 1288 indicate the origin, not the TargetName. 1290 8.5. HTTP Strict Transport Security 1292 By publishing a usable HTTPS RR, the server operator indicates that 1293 all useful HTTP resources on that origin are reachable over HTTPS, 1294 similar to HTTP Strict Transport Security [HSTS]. 1296 Prior to making an "http" scheme request, the client SHOULD perform a 1297 lookup to determine if any HTTPS RRs exist for that origin. To do 1298 so, the client SHOULD construct a corresponding "https" URL as 1299 follows: 1301 1. Replace the "http" scheme with "https". 1303 2. If the "http" URL explicitly specifies port 80, specify port 443. 1305 3. Do not alter any other aspect of the URL. 1307 This construction is equivalent to Section 8.3 of [HSTS], point 5. 1309 If an HTTPS RR query for this "https" URL returns any AliasMode HTTPS 1310 RRs, or any compatible ServiceMode HTTPS RRs (see Section 7), the 1311 client SHOULD act as if it has received an HTTP "307 Temporary 1312 Redirect" redirect to this "https" URL. (Receipt of an incompatible 1313 ServiceMode RR does not trigger the redirect behavior.) Because 1314 HTTPS RRs are received over an often insecure channel (DNS), clients 1315 MUST NOT place any more trust in this signal than if they had 1316 received a 307 redirect over cleartext HTTP. 1318 When an HTTPS connection fails due to an error in the underlying 1319 secure transport, such as an error in certificate validation, some 1320 clients currently offer a "user recourse" that allows the user to 1321 bypass the security error and connect anyway. When making an "https" 1322 scheme request to an origin with an HTTPS RR, either directly or via 1323 the above redirect, such a client MAY remove the user recourse 1324 option. Origins that publish HTTPS RRs therefore MUST NOT rely on 1325 user recourse for access. For more information, see Section 8.4 and 1326 Section 12.1 of [HSTS]. 1328 8.6. HTTP-based protocols 1330 All protocols employing "http://" or "https://" URLs SHOULD respect 1331 HTTPS RRs. For example, clients that support HTTPS RRs and implement 1332 the altered WebSocket [WebSocket] opening handshake from the W3C 1333 Fetch specification [FETCH] SHOULD use HTTPS RRs for the 1334 "requestURL". 1336 An HTTP-based protocol MAY define its own SVCB mapping. Such 1337 mappings MAY be defined to take precedence over HTTPS RRs. 1339 9. SVCB/HTTPS RR parameter for ECH configuration 1341 The SVCB "ech" parameter is defined for conveying the ECH 1342 configuration of an alternative endpoint. In wire format, the value 1343 of the parameter is an ECHConfigList [ECH], including the redundant 1344 length prefix. In presentation format, the value is a single 1345 ECHConfigList encoded in Base64 [base64]. Base64 is used here to 1346 simplify integration with TLS server software. To enable simpler 1347 parsing, this SvcParam MUST NOT contain escape sequences. 1349 When ECH is in use, the TLS ClientHello is divided into an 1350 unencrypted "outer" and an encrypted "inner" ClientHello. The outer 1351 ClientHello is an implementation detail of ECH, and its contents are 1352 controlled by the ECHConfig in accordance with [ECH]. The inner 1353 ClientHello is used for establishing a connection to the service, so 1354 its contents may be influenced by other SVCB parameters. For 1355 example, the requirements on the ProtocolNameList in Section 6.1 1356 apply only to the inner ClientHello. Similarly, it is the inner 1357 ClientHello whose Server Name Indication identifies the desired 1358 service. 1360 9.1. Client behavior 1362 The SVCB-optional client behavior specified in Section 3 permits 1363 clients to fall back to a direct connection if all SVCB options fail. 1364 This behavior is not suitable for ECH, because fallback would negate 1365 the privacy benefits of ECH. Accordingly, ECH-capable SVCB-optional 1366 clients MUST switch to SVCB-reliant connection establishment if SVCB 1367 resolution succeeded (following Section 3) and all alternative 1368 endpoints have an "ech" key. 1370 As a latency optimization, clients MAY prefetch DNS records that will 1371 only be used in SVCB-optional mode. 1373 9.2. Deployment considerations 1375 An HTTPS RRSet containing some RRs with "ech" and some without is 1376 vulnerable to a downgrade attack. This configuration is NOT 1377 RECOMMENDED. Zone owners who do use such a mixed configuration 1378 SHOULD mark the RRs with "ech" as more preferred (i.e. smaller 1379 SvcPriority) than those without, in order to maximize the likelihood 1380 that ECH will be used in the absence of an active adversary. 1382 10. Zone Structures 1384 10.1. Structuring zones for flexibility 1386 Each ServiceForm RRSet can only serve a single scheme. The scheme is 1387 indicated by the owner name and the RR type. For the generic SVCB RR 1388 type, this means that each owner name can only be used for a single 1389 scheme. The underscore prefixing requirement (Section 2.3) ensures 1390 that this is true for the initial query, but it is the responsibility 1391 of zone owners to choose names that satisfy this constraint when 1392 using aliases, including CNAME and AliasMode records. 1394 When using the generic SVCB RR type with aliasing, zone owners SHOULD 1395 choose alias target names that indicate the scheme in use (e.g. 1396 "foosvc.example.net" for "foo://" schemes). This will help to avoid 1397 confusion when another scheme needs to be added to the configuration. 1399 10.2. Structuring zones for performance 1401 To avoid a delay for clients using a nonconforming recursive 1402 resolver, domain owners SHOULD minimize the use of AliasMode records, 1403 and SHOULD choose TargetName according to a predictable convention 1404 that is known to the client, so that clients can issue A and/or AAAA 1405 queries for TargetName in advance (see Section 5). Unless otherwise 1406 specified, the convention is to set TargetName to the service name 1407 for an initial ServiceMode record, or to "." if it is reached via an 1408 alias. For foo://foo.example.com:8080, this might look like: 1410 $ORIGIN example.com. ; Origin 1411 foo 3600 IN CNAME foosvc.example.net. 1412 _8080._foo.foo 3600 IN CNAME foosvc.example.net. 1414 $ORIGIN example.net. ; Service provider zone 1415 foosvc 3600 IN SVCB 1 . key65333=... 1416 foosvc 300 IN AAAA 2001:db8::1 1417 Domain owners SHOULD avoid using a TargetName that is below a DNAME, 1418 as this is likely unnecessary and makes responses slower and larger. 1419 Also, zone structures that require following more than 8 aliases 1420 (counting both AliasMode and CNAME records) are NOT RECOMMENDED. 1422 10.3. Examples 1424 10.3.1. Protocol enhancements 1426 Consider a simple zone of the form: 1428 $ORIGIN simple.example. ; Simple example zone 1429 @ 300 IN A 192.0.2.1 1430 AAAA 2001:db8::1 1432 The domain owner could add this record: 1434 @ 7200 IN HTTPS 1 . alpn=h3 1436 to indicate that https://simple.example supports QUIC in addition to 1437 HTTPS over TCP (an implicit default). The record could also include 1438 other information (e.g. non-standard port, ECH configuration). For 1439 https://simple.example:8443, the record would be: 1441 _8443._https 7200 IN HTTPS 1 . alpn=h3 1443 These records also respectively tell clients to replace the scheme 1444 with "https" when loading http://simple.example or 1445 http://simple.example:8443. 1447 10.3.2. Apex aliasing 1449 Consider a zone that is using CNAME aliasing: 1451 $ORIGIN aliased.example. ; A zone that is using a hosting service 1452 ; Subdomain aliased to a high-performance server pool 1453 www 7200 IN CNAME pool.svc.example. 1454 ; Apex domain on fixed IPs because CNAME is not allowed at the apex 1455 @ 300 IN A 192.0.2.1 1456 IN AAAA 2001:db8::1 1458 With HTTPS RRs, the owner of aliased.example could alias the apex by 1459 adding one additional record: 1461 @ 7200 IN HTTPS 0 pool.svc.example. 1463 With this record in place, HTTPS-RR-aware clients will use the same 1464 server pool for aliased.example and www.aliased.example. (They will 1465 also upgrade to HTTPS on aliased.example.) Non-HTTPS-RR-aware 1466 clients will just ignore the new record. 1468 Similar to CNAME, HTTPS RRs have no impact on the origin name. When 1469 connecting, clients will continue to treat the authoritative origins 1470 as "https://www.aliased.example" and "https://aliased.example", 1471 respectively, and will validate TLS server certificates accordingly. 1473 10.3.3. Parameter binding 1475 Suppose that svc.example's default server pool supports HTTP/2, and 1476 it has deployed HTTP/3 on a new server pool with a different 1477 configuration. This can be expressed in the following form: 1479 $ORIGIN svc.example. ; A hosting provider. 1480 pool 7200 IN HTTPS 1 h3pool alpn=h2,h3 ech="123..." 1481 HTTPS 2 . alpn=h2 ech="abc..." 1482 pool 300 IN A 192.0.2.2 1483 AAAA 2001:db8::2 1484 h3pool 300 IN A 192.0.2.3 1485 AAAA 2001:db8::3 1487 This configuration is entirely compatible with the "Apex aliasing" 1488 example, whether the client supports HTTPS RRs or not. If the client 1489 does support HTTPS RRs, all connections will be upgraded to HTTPS, 1490 and clients will use HTTP/3 if they can. Parameters are "bound" to 1491 each server pool, so each server pool can have its own protocol, ECH 1492 configuration, etc. 1494 10.3.4. Multi-CDN 1496 The HTTPS RR is intended to support HTTPS services operated by 1497 multiple independent entities, such as different Content Delivery 1498 Networks (CDNs) or different hosting providers. This includes the 1499 case where a service is migrated from one operator to another, as 1500 well as the case where the service is multiplexed between multiple 1501 operators for performance, redundancy, etc. 1503 This example shows such a configuration, with www.customer.example 1504 having different DNS responses to different queries, either over time 1505 or due to logic within the authoritative DNS server: 1507 ; This zone contains/returns different CNAME records 1508 ; at different points-in-time. The RRset for "www" can 1509 ; only ever contain a single CNAME. 1511 ; Sometimes the zone has: 1512 $ORIGIN customer.example. ; A Multi-CDN customer domain 1513 www 900 IN CNAME cdn1.svc1.example. 1515 ; and other times it contains: 1516 $ORIGIN customer.example. 1517 www 900 IN CNAME customer.svc2.example. 1519 ; and yet other times it contains: 1520 $ORIGIN customer.example. 1521 www 900 IN CNAME cdn3.svc3.example. 1523 ; With the following remaining constant and always included: 1524 $ORIGIN customer.example. ; A Multi-CDN customer domain 1525 ; The apex is also aliased to www to match its configuration 1526 @ 7200 IN HTTPS 0 www 1527 ; Non-HTTPS-aware clients use non-CDN IPs 1528 A 203.0.113.82 1529 AAAA 2001:db8:203::2 1531 ; Resolutions following the cdn1.svc1.example 1532 ; path use these records. 1533 ; This CDN uses a different alternative service for HTTP/3. 1534 $ORIGIN svc1.example. ; domain for CDN 1 1535 cdn1 1800 IN HTTPS 1 h3pool alpn=h3 ech="123..." 1536 HTTPS 2 . alpn=h2 ech="123..." 1537 A 192.0.2.2 1538 AAAA 2001:db8:192::4 1539 h3pool 300 IN A 192.0.2.3 1540 AAAA 2001:db8:192:7::3 1542 ; Resolutions following the customer.svc2.example 1543 ; path use these records. 1544 ; Note that this CDN only supports HTTP/2. 1545 $ORIGIN svc2.example. ; domain operated by CDN 2 1546 customer 300 IN HTTPS 1 . alpn=h2 ech="xyz..." 1547 60 IN A 198.51.100.2 1548 A 198.51.100.3 1549 A 198.51.100.4 1550 AAAA 2001:db8:198::7 1551 AAAA 2001:db8:198::12 1553 ; Resolutions following the customer.svc2.example 1554 ; path use these records. 1556 ; Note that this CDN has no HTTPS records 1557 ; and thus no ECH support. 1558 $ORIGIN svc3.example. ; domain operated by CDN 3 1559 cdn3 60 IN A 203.0.113.8 1560 AAAA 2001:db8:113::8 1562 Note that in the above example, the different CDNs have different ECH 1563 configurations and different capabilities, but clients will use HTTPS 1564 RRs as a bound-together unit. 1566 Domain owners should be cautious when using a multi-CDN 1567 configuration, as it introduces a number of complexities highlighted 1568 by this example: 1570 * If CDN 1 supports ECH, and CDN 2 does not, the client is 1571 vulnerable to ECH downgrade by a network adversary who forces 1572 clients to get CDN 2 records. 1574 * Aliasing the apex to its subdomain simplifies the zone file but 1575 likely increases resolution latency, especially when using a non- 1576 HTTPS-aware recursive resolver. An alternative would be to alias 1577 the zone apex directly to a name managed by a CDN. 1579 * The A, AAAA, HTTPS resolutions are independent lookups so clients 1580 may observe and follow different CNAMEs to different CDNs. 1581 Clients may thus find a SvcDomainName pointing to a name other 1582 than the one which returned along with the A and AAAA lookups and 1583 will need to do an additional resolution for them. Including 1584 ipv6hint and ipv4hint will reduce the performance impact of this 1585 case. 1587 * If not all CDNs publish HTTPS records, clients will sometimes 1588 receive NODATA for HTTPS queries (as with cdn3.svc3.example 1589 above), and thus no "ech" SvcParam, but could receive A/AAAA 1590 records from a different CDN which does support ECH. Clients will 1591 be unable to use ECH in this case. 1593 10.3.5. Non-HTTPS uses 1595 For services other than HTTPS, the SVCB RR and an Attrleaf label 1596 [Attrleaf] will be used. For example, to reach an example resource 1597 of "baz://api.example.com:8765", the following SVCB record would be 1598 used to alias it to "svc4-baz.example.net." which in-turn could 1599 return AAAA/A records and/or SVCB records in ServiceMode: 1601 _8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net. 1603 HTTPS RRs use similar Attrleaf labels if the origin contains a non- 1604 default port. 1606 11. Interaction with other standards 1608 This standard is intended to reduce connection latency and improve 1609 user privacy. Server operators implementing this standard SHOULD 1610 also implement TLS 1.3 [RFC8446] and OCSP Stapling [RFC6066], both of 1611 which confer substantial performance and privacy benefits when used 1612 in combination with SVCB records. 1614 To realize the greatest privacy benefits, this proposal is intended 1615 for use over a privacy-preserving DNS transport (like DNS over TLS 1616 [DoT] or DNS over HTTPS [DoH]). However, performance improvements, 1617 and some modest privacy improvements, are possible without the use of 1618 those standards. 1620 Any specification for use of SVCB with a protocol MUST have an entry 1621 for its scheme under the SVCB RR type in the IANA DNS Underscore 1622 Global Scoped Entry Registry [Attrleaf]. The scheme SHOULD have an 1623 entry in the IANA URI Schemes Registry [RFC7595]. The scheme SHOULD 1624 have a defined specification for use with SVCB. 1626 12. Security Considerations 1628 SVCB/HTTPS RRs are intended for distribution over untrusted channels, 1629 and clients are REQUIRED to verify that the alternative endpoint is 1630 authoritative for the service (similar to Section 2.1 of [AltSvc]). 1631 Therefore, DNSSEC signing and validation are OPTIONAL for publishing 1632 and using SVCB and HTTPS RRs. 1634 Clients MUST ensure that their DNS cache is partitioned for each 1635 local network, or flushed on network changes, to prevent a local 1636 adversary in one network from implanting a forged DNS record that 1637 allows them to track users or hinder their connections after they 1638 leave that network. 1640 An attacker who can prevent SVCB resolution can deny clients any 1641 associated security benefits. A hostile recursive resolver can 1642 always deny service to SVCB queries, but network intermediaries can 1643 often prevent resolution as well, even when the client and recursive 1644 resolver validate DNSSEC and use a secure transport. These downgrade 1645 attacks can prevent the HTTPS upgrade provided by the HTTPS RR 1646 (Section 8.5), and disable the encryption enabled by the "ech" 1647 SvcParamKey (Section 9). To prevent downgrades, Section 3.1 1648 recommends that clients abandon the connection attempt when such an 1649 attack is detected. 1651 A hostile DNS intermediary might forge AliasForm "." records 1652 (Section 2.5.1) as a way to block clients from accessing particular 1653 services. Such an adversary could already block entire domains by 1654 forging erroneous responses, but this mechanism allows them to target 1655 particular protocols or ports within a domain. Clients that might be 1656 subject to such attacks SHOULD ignore AliasForm "." records. 1658 A hostile DNS intermediary or origin can return SVCB records 1659 indicating any IP address and port number, including IP addresses 1660 inside the local network and port numbers assigned to internal 1661 services. If the attacker can influence the client's payload (e.g. 1662 TLS session ticket contents), and an internal service has a 1663 sufficiently lax parser, it's possible that the attacker could gain 1664 unintended access. (The same concerns apply to SRV records, HTTP 1665 Alt-Svc, and HTTP redirects.) As a mitigation, SVCB mapping 1666 documents SHOULD indicate any port number restrictions that are 1667 appropriate for the supported transports. 1669 13. Privacy Considerations 1671 Standard address queries reveal the user's intent to access a 1672 particular domain. This information is visible to the recursive 1673 resolver, and to many other parties when plaintext DNS transport is 1674 used. SVCB queries, like queries for SRV records and other specific 1675 RR types, additionally reveal the user's intent to use a particular 1676 protocol. This is not normally sensitive information, but it should 1677 be considered when adding SVCB support in a new context. 1679 14. IANA Considerations 1681 14.1. SVCB RRType 1683 This document defines a new DNS RR type, SVCB, whose value 64 has 1684 been allocated by IANA from the "Resource Record (RR) TYPEs" 1685 subregistry of the "Domain Name System (DNS) Parameters" registry: 1687 Type: SVCB 1689 Value: 64 1691 Meaning: General Purpose Service Endpoints 1693 Reference: This document 1695 14.2. HTTPS RRType 1697 This document defines a new DNS RR type, HTTPS, whose value 65 has 1698 been allocated by IANA from the "Resource Record (RR) TYPEs" 1699 subregistry of the "Domain Name System (DNS) Parameters" registry: 1701 Type: HTTPS 1703 Value: 65 1705 Meaning: HTTPS Specific Service Endpoints 1707 Reference: This document 1709 14.3. New registry for Service Parameters 1711 The "Service Binding (SVCB) Parameter Registry" defines the namespace 1712 for parameters, including string representations and numeric 1713 SvcParamKey values. This registry is shared with other SVCB- 1714 compatible RR types, such as the HTTPS RR. 1716 ACTION: create and include a reference to this registry. 1718 14.3.1. Procedure 1720 A registration MUST include the following fields: 1722 * Number: wire format numeric identifier (range 0-65535) 1724 * Name: unique presentation name 1726 * Meaning: a short description 1728 * Format Reference: pointer to specification text 1730 The characters in the registered Name MUST be lower-case alphanumeric 1731 or "-" (Section 2.1). The name MUST NOT start with "key" or 1732 "invalid". 1734 Entries in this registry are subject to a First Come First Served 1735 registration policy ([RFC8126], Section 4.4). The Format Reference 1736 MUST specify how to convert the SvcParamValue's presentation format 1737 to wire format and MAY detail its intended meaning and use. An entry 1738 MAY specify a Format Reference of the form "Same as (other key Name)" 1739 if it uses the same presentation and wire formats as an existing key. 1741 This arrangement supports the development of new parameters while 1742 ensuring that zone files can be made interoperable. 1744 14.3.2. Initial contents 1746 The "Service Binding (SVCB) Parameter Registry" shall initially be 1747 populated with the registrations below: 1749 +=============+=================+================+=================+ 1750 | Number | Name | Meaning | Format | 1751 | | | | Reference | 1752 +=============+=================+================+=================+ 1753 | 0 | mandatory | Mandatory keys | (This document) | 1754 | | | in this RR | Section 7 | 1755 +-------------+-----------------+----------------+-----------------+ 1756 | 1 | alpn | Additional | (This document) | 1757 | | | supported | Section 6.1 | 1758 | | | protocols | | 1759 +-------------+-----------------+----------------+-----------------+ 1760 | 2 | no-default-alpn | No support for | (This document) | 1761 | | | default | Section 6.1 | 1762 | | | protocol | | 1763 +-------------+-----------------+----------------+-----------------+ 1764 | 3 | port | Port for | (This document) | 1765 | | | alternative | Section 6.2 | 1766 | | | endpoint | | 1767 +-------------+-----------------+----------------+-----------------+ 1768 | 4 | ipv4hint | IPv4 address | (This document) | 1769 | | | hints | Section 6.4 | 1770 +-------------+-----------------+----------------+-----------------+ 1771 | 5 | ech | Encrypted | (This document) | 1772 | | | ClientHello | Section 6.3 | 1773 | | | info | | 1774 +-------------+-----------------+----------------+-----------------+ 1775 | 6 | ipv6hint | IPv6 address | (This document) | 1776 | | | hints | Section 6.4 | 1777 +-------------+-----------------+----------------+-----------------+ 1778 | 65280-65534 | N/A | Private Use | (This document) | 1779 +-------------+-----------------+----------------+-----------------+ 1780 | 65535 | N/A | Reserved | (This document) | 1781 | | | ("Invalid | | 1782 | | | key") | | 1783 +-------------+-----------------+----------------+-----------------+ 1785 Table 1 1787 14.4. Registry updates 1789 Per [RFC6895], please add the following entries to the data type 1790 range of the Resource Record (RR) TYPEs registry: 1792 +=======+========================================+=================+ 1793 | TYPE | Meaning | Reference | 1794 +=======+========================================+=================+ 1795 | SVCB | Service Location and Parameter Binding | (This document) | 1796 +-------+----------------------------------------+-----------------+ 1797 | HTTPS | HTTPS Service Location and Parameter | (This document) | 1798 | | Binding | | 1799 +-------+----------------------------------------+-----------------+ 1801 Table 2 1803 Per [Attrleaf], please add the following entry to the DNS Underscore 1804 Global Scoped Entry Registry: 1806 +=========+============+=================+=================+ 1807 | RR TYPE | _NODE NAME | Meaning | Reference | 1808 +=========+============+=================+=================+ 1809 | HTTPS | _https | HTTPS SVCB info | (This document) | 1810 +---------+------------+-----------------+-----------------+ 1812 Table 3 1814 15. Acknowledgments and Related Proposals 1816 There have been a wide range of proposed solutions over the years to 1817 the "CNAME at the Zone Apex" challenge proposed. These include 1818 [I-D.bellis-dnsop-http-record], [I-D.ietf-dnsop-aname], and others. 1820 Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thomson, Lucas 1821 Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, David 1822 Benjamin, Mark Andrews, Emily Stark, Eric Orth, Kyle Rose, Craig 1823 Taylor, Dan McArdle, Brian Dickson, Willem Toorop, Pieter Lexis, 1824 Puneet Sood, Olivier Poitrey, Mashooq Muhaimen, Tom Carpay, and many 1825 others for their feedback and suggestions on this draft. 1827 16. References 1829 16.1. Normative References 1831 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1832 "Transport Layer Security (TLS) Application-Layer Protocol 1833 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1834 July 2014, . 1836 [Attrleaf] Crocker, D., "Scoped Interpretation of DNS Resource 1837 Records through "Underscored" Naming of Attribute Leaves", 1838 BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, 1839 . 1841 [base64] Josefsson, S., "The Base16, Base32, and Base64 Data 1842 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1843 . 1845 [DNAME] Rose, S. and W. Wijngaards, "DNAME Redirection in the 1846 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 1847 . 1849 [DoH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1850 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1851 . 1853 [DoT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1854 and P. Hoffman, "Specification for DNS over Transport 1855 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1856 2016, . 1858 [ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 1859 Encrypted Client Hello", Work in Progress, Internet-Draft, 1860 draft-ietf-tls-esni-12, 7 July 2021, 1861 . 1864 [HappyEyeballsV2] 1865 Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1866 Better Connectivity Using Concurrency", RFC 8305, 1867 DOI 10.17487/RFC8305, December 2017, 1868 . 1870 [HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1871 Transport Security (HSTS)", RFC 6797, 1872 DOI 10.17487/RFC6797, November 2012, 1873 . 1875 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 1876 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 1877 quic-http-34, 2 February 2021, 1878 . 1881 [RFC1035] Mockapetris, P.V., "Domain names - implementation and 1882 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1883 November 1987, . 1885 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1886 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1887 DOI 10.17487/RFC1928, March 1996, 1888 . 1890 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1891 Requirement Levels", BCP 14, RFC 2119, 1892 DOI 10.17487/RFC2119, March 1997, 1893 . 1895 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1896 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 1897 . 1899 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 1900 RFC 3225, DOI 10.17487/RFC3225, December 2001, 1901 . 1903 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 1904 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 1905 2003, . 1907 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1908 Specifications: ABNF", STD 68, RFC 5234, 1909 DOI 10.17487/RFC5234, January 2008, 1910 . 1912 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1913 Address Text Representation", RFC 5952, 1914 DOI 10.17487/RFC5952, August 2010, 1915 . 1917 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1918 Extensions: Extension Definitions", RFC 6066, 1919 DOI 10.17487/RFC6066, January 2011, 1920 . 1922 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1923 Beijnum, "DNS64: DNS Extensions for Network Address 1924 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1925 DOI 10.17487/RFC6147, April 2011, 1926 . 1928 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1929 the IPv6 Prefix Used for IPv6 Address Synthesis", 1930 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1931 . 1933 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1934 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1935 DOI 10.17487/RFC7231, June 2014, 1936 . 1938 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 1939 and Registration Procedures for URI Schemes", BCP 35, 1940 RFC 7595, DOI 10.17487/RFC7595, June 2015, 1941 . 1943 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 1944 Kumari, "Client Subnet in DNS Queries", RFC 7871, 1945 DOI 10.17487/RFC7871, May 2016, 1946 . 1948 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1949 Writing an IANA Considerations Section in RFCs", BCP 26, 1950 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1951 . 1953 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1954 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1955 May 2017, . 1957 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1958 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1959 . 1961 [WebSocket] 1962 Fette, I. and A. Melnikov, "The WebSocket Protocol", 1963 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1964 . 1966 16.2. Informative References 1968 [AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1969 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1970 April 2016, . 1972 [DNSTerm] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1973 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1974 January 2019, . 1976 [FETCH] "Fetch Living Standard", May 2020, 1977 . 1979 [I-D.bellis-dnsop-http-record] 1980 Bellis, R., "A DNS Resource Record for HTTP", Work in 1981 Progress, Internet-Draft, draft-bellis-dnsop-http-record- 1982 00, 3 November 2018, 1983 . 1986 [I-D.ietf-dnsop-aname] 1987 Finch, T., Hunt, E., Dijk, P. V., Eden, A., and M. 1988 Mekking, "Address-specific DNS aliases (ANAME)", Work in 1989 Progress, Internet-Draft, draft-ietf-dnsop-aname-04, 8 1990 July 2019, . 1993 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1994 (IPv6) Addressing Architecture", RFC 3513, 1995 DOI 10.17487/RFC3513, April 2003, 1996 . 1998 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1999 DOI 10.17487/RFC6454, December 2011, 2000 . 2002 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 2003 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 2004 April 2013, . 2006 [SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2007 specifying the location of services (DNS SRV)", RFC 2782, 2008 DOI 10.17487/RFC2782, February 2000, 2009 . 2011 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2012 Resource Identifier (URI): Generic Syntax", STD 66, 2013 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2014 . 2016 Appendix A. Decoding text in zone files 2018 DNS zone files are capable of representing arbitrary octet sequences 2019 in basic ASCII text, using various delimiters and encodings. The 2020 algorithm for decoding these character-strings is defined in 2021 Section 5.1 of [RFC1035]. Here we summarize the allowed input to 2022 that algorithm, using ABNF: 2024 ; non-special is VCHAR minus DQUOTE, ";", "(", ")", and "\". 2025 non-special = %x21 / %x23-27 / %x2A-3A / %x3C-5B / %x5D-7E 2026 ; non-digit is VCHAR minus DIGIT 2027 non-digit = %x21-2F / %x3A-7E 2028 ; dec-octet is a number 0-255 as a three-digit decimal number. 2029 dec-octet = ( "0" / "1" ) 2DIGIT / 2030 "2" ( ( %x30-34 DIGIT ) / ( "5" %x30-35 ) ) 2031 escaped = "\" ( non-digit / dec-octet ) 2032 contiguous = 1*( non-special / escaped ) 2033 quoted = DQUOTE *( contiguous / ( ["\"] WSP ) ) DQUOTE 2034 char-string = contiguous / quoted 2036 The decoding algorithm allows "char-string" to represent any 2037 "*OCTET". In this document, this algorithm is referred to as 2038 "character-string decoding". The algorithm is the same as used by 2039 "" in RFC 1035, although the output length in this 2040 document is not limited to 255 octets. 2042 A.1. Decoding a comma-separated list 2044 In order to represent lists of items in zone files, this 2045 specification uses comma-separated lists. When the allowed items in 2046 the list cannot contain "," or "\", this is trivial. (For 2047 simplicity, empty items are not allowed.) A value-list parser that 2048 splits on "," and prohibits items containing "\" is sufficient to 2049 comply with all requirements in this document. 2051 For implementations that allow "," and "\" in item values, the 2052 following escaping syntax applies: 2054 item = 1*OCTET 2055 ; item-allowed is OCTET minus "," and "\". 2056 item-allowed = %x00-2B / %x2D-5B / %x5D-FF 2057 escaped-item = 1*(item-allowed / "\," / "\\") 2058 comma-separated = [escaped-item *("," escaped-item)] 2060 Decoding of value-lists happens after character-string decoding. 2061 For example, consider these "char-string" SvcParamValues: 2063 "part1,part2,part3\\,part4\\\\" 2064 part1\,\p\a\r\t2\044part3\092,part4\092\\ 2066 These inputs are equivalent: character-string decoding either of them 2067 would produce the same "value": 2069 part1,part2,part3\,part4\\ 2070 Applying comma-separated list decoding to this "value" would produce 2071 a list of three "item"s: 2073 part1 2074 part2 2075 part3,part4\ 2077 Appendix B. HTTP Mapping Summary 2079 This table serves as a non-normative summary of the HTTP mapping for 2080 SVCB (Section 8). Future protocol mappings may provide a similar 2081 summary table. 2083 +==========================+======================+ 2084 +==========================+======================+ 2085 | *Mapped scheme* | "https" | 2086 +--------------------------+----------------------+ 2087 | *Other affected schemes* | "http", "wss", "ws", | 2088 | | (other HTTP-based) | 2089 +--------------------------+----------------------+ 2090 | *RR type* | HTTPS (65) | 2091 +--------------------------+----------------------+ 2092 | *Name prefix* | None for port 443, | 2093 | | else "_$PORT._https" | 2094 +--------------------------+----------------------+ 2095 | *Automatically Mandatory | "port", "no-default- | 2096 | Keys* | alpn" | 2097 +--------------------------+----------------------+ 2098 | *SvcParam defaults* | "alpn": ["http/1.1"] | 2099 +--------------------------+----------------------+ 2100 | *Special behaviors* | HTTP to HTTPS | 2101 | | upgrade | 2102 +--------------------------+----------------------+ 2104 Table 4 2106 This table does not indicate any SvcParamKeys that servers are 2107 required to publish, or that clients are required to implement, 2108 because there are none in this mapping. 2110 Appendix C. Comparison with alternatives 2112 The SVCB and HTTPS RR types closely resemble, and are inspired by, 2113 some existing record types and proposals. A complaint with all of 2114 the alternatives is that web clients have seemed unenthusiastic about 2115 implementing them. The hope here is that by providing an extensible 2116 solution that solves multiple problems we will overcome the inertia 2117 and have a path to achieve client implementation. 2119 C.1. Differences from the SRV RR type 2121 An SRV record [SRV] can perform a similar function to the SVCB 2122 record, informing a client to look in a different location for a 2123 service. However, there are several differences: 2125 * SRV records are typically mandatory, whereas clients will always 2126 continue to function correctly without making use of SVCB. 2128 * SRV records cannot instruct the client to switch or upgrade 2129 protocols, whereas SVCB can signal such an upgrade (e.g. to 2130 HTTP/2). 2132 * SRV records are not extensible, whereas SVCB and HTTPS RRs can be 2133 extended with new parameters. 2135 * SVCB records use 16 bit for SvcPriority for consistency with SRV 2136 and other RR types that also use 16 bit priorities. 2138 C.2. Differences from the proposed HTTP record 2140 Unlike [I-D.bellis-dnsop-http-record], this approach is extensible to 2141 cover Alt-Svc and Encrypted ClientHello use-cases. Like that 2142 proposal, this addresses the zone apex CNAME challenge. 2144 Like that proposal, it remains necessary to continue to include 2145 address records at the zone apex for legacy clients. 2147 C.3. Differences from the proposed ANAME record 2149 Unlike [I-D.ietf-dnsop-aname], this approach is extensible to cover 2150 Alt-Svc and ECH use-cases. This approach also does not require any 2151 changes or special handling on either authoritative or primary 2152 servers, beyond optionally returning in-bailiwick additional records. 2154 Like that proposal, this addresses the zone apex CNAME challenge for 2155 clients that implement this. 2157 However, with this SVCB proposal, it remains necessary to continue to 2158 include address records at the zone apex for legacy clients. If 2159 deployment of this standard is successful, the number of legacy 2160 clients will fall over time. As the number of legacy clients 2161 declines, the operational effort required to serve these users 2162 without the benefit of SVCB indirection should fall. Server 2163 operators can easily observe how much traffic reaches this legacy 2164 endpoint, and may remove the apex's address records if the observed 2165 legacy traffic has fallen to negligible levels. 2167 C.4. Comparison with separate RR types for AliasMode and ServiceMode 2169 Abstractly, functions of AliasMode and ServiceMode are independent, 2170 so it might be tempting to specify them as separate RR types. 2171 However, this would result in a serious performance impairment, 2172 because clients cannot rely on their recursive resolver to follow 2173 SVCB aliases (unlike CNAME). Thus, clients would have to issue 2174 queries for both RR types in parallel, potentially at each step of 2175 the alias chain. Recursive resolvers that implement the 2176 specification would, upon receipt of a ServiceMode query, emit both a 2177 ServiceMode and an AliasMode query to the authoritative. Thus, 2178 splitting the RR type would double, or in some cases triple, the load 2179 on clients and servers, and would not reduce implementation 2180 complexity. 2182 Appendix D. Test vectors 2184 These test vectors only contain the RDATA portion of SVCB/HTTPS 2185 records in presentation format, generic format ([RFC3597]) and wire 2186 format. The wire format uses hexadecimal (\xNN) for each non-ascii 2187 byte. As the wireformat is long, it is broken into several lines. 2189 D.1. AliasForm 2191 example.com. HTTPS 0 foo.example.com. 2193 \# 19 ( 2194 00 00 ; priority 2195 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2196 ) 2198 \x00\x00 # priority 2199 \x03foo\x07example\x03com\x00 # target 2201 D.2. ServiceForm 2203 The first form is the simple "use the ownername". 2205 example.com. SVCB 1 . 2207 \# 3 ( 2208 00 01 ; priority 2209 00 ; target (root label) 2210 ) 2212 \x00\x01 # priority 2213 \x00 # target, root label 2214 This vector only has a port. 2216 example.com. SVCB 16 foo.example.com. port=53 2218 \# 25 ( 2219 00 10 ; priority 2220 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2221 00 03 ; key 3 2222 00 02 ; length 2 2223 00 35 ; value 2224 ) 2226 \x00\x10 # priority 2227 \x03foo\x07example\x03com\x00 # target 2228 \x00\x03 # key 3 2229 \x00\x02 # length: 2 bytes 2230 \x00\x35 # value 2232 This example has a key that is not registered, its value is unquoted. 2234 example.com. SVCB 1 foo.example.com. key667=hello 2236 \# 28 ( 2237 00 01 ; priority 2238 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2239 02 9b ; key 667 2240 00 05 ; length 5 2241 68 65 6c 6c 6f ; value 2242 ) 2244 \x00\x01 # priority 2245 \x03foo\x07example\x03com\x00 # target 2246 \x02\x9b # key 667 2247 \x00\x05 # length 5 2248 hello # value 2250 This example has a key that is not registered, its value is quoted 2251 and contains a decimal-escaped character. 2253 example.com. SVCB 1 foo.example.com. key667="hello\210qoo" 2255 \# 32 ( 2256 00 01 ; priority 2257 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2258 02 9b ; key 667 2259 00 09 ; length 9 2260 68 65 6c 6c 6f d2 71 6f 6f ; value 2261 ) 2263 \x00\x01 # priority 2264 \x03foo\x07example\x03com\x00 # target 2265 \x02\x9b # key 667 2266 \x00\x09 # length 9 2267 hello\xd2qoo # value 2269 Here, two IPv6 hints are quoted in the presentation format. 2271 example.com. SVCB 1 foo.example.com. ( 2272 ipv6hint="2001:db8::1,2001:db8::53:1" 2273 ) 2275 \# 55 ( 2276 00 01 ; priority 2277 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2278 00 06 ; key 6 2279 00 20 ; length 32 2280 20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01 ; first address 2281 20 01 0d b8 00 00 00 00 00 00 00 00 00 53 00 01 ; second address 2282 ) 2284 \x00\x01 # priority 2285 \x03foo\x07example\x03com\x00 # target 2286 \x00\x06 # key 6 2287 \x00\x20 # length 32 2288 \x20\x01\x0d\xb8\x00\x00\x00\x00 2289 \x00\x00\x00\x00\x00\x00\x00\x01 # first address 2290 \x20\x01\x0d\xb8\x00\x00\x00\x00 2291 \x00\x00\x00\x00\x00\x53\x00\x01 # second address 2293 This example shows a single IPv6 hint in IPv4-mapped IPv6 2294 presentation format([RFC3513]). 2296 example.com. SVCB 1 example.com. ipv6hint="::ffff:198.51.100.100" 2298 \# 35 ( 2299 00 01 ; priority 2300 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 2301 00 06 ; key 6 2302 00 10 ; length 16 2303 00 00 00 00 00 00 00 00 00 00 ff ff c6 33 64 64 ; address 2304 ) 2306 \x00\x01 # priority 2307 \x07example\x03com\x00 # target 2308 \x00\x06 # key 6 2309 \x00\x10 # length 16 2310 \x00\x00\x00\x00\x00\x00\x00\x00 2311 \x00\x00\xff\xff\xc6\x33\x64\x64 # address 2313 In the next vector, neither the SvcParamValues nor the mandatory keys 2314 are sorted in presentation format, but are correctly sorted in the 2315 wire-format. 2317 example.com. SVCB 16 foo.example.org. ( 2318 alpn=h2,h3-19 mandatory=ipv4hint,alpn 2319 ipv4hint=192.0.2.1 2320 ) 2322 \# 48 ( 2323 00 10 ; priority 2324 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target 2325 00 00 ; key 0 2326 00 04 ; param length 4 2327 00 01 ; value: key 1 2328 00 04 ; value: key 4 2329 00 01 ; key 1 2330 00 09 ; param length 9 2331 02 ; alpn length 2 2332 68 32 ; alpn value 2333 05 ; alpn length 5 2334 68 33 2d 31 39 ; alpn value 2335 00 04 ; key 4 2336 00 04 ; param length 4 2337 c0 00 02 01 ; param value 2338 ) 2340 \x00\x10 # priority 2341 \x03foo\x07example\x03org\x00 # target 2342 \x00\x00 # key 0 2343 \x00\x04 # param length 4 2344 \x00\x01 # value: key 1 2345 \x00\x04 # value: key 4 2346 \x00\x01 # key 1 2347 \x00\x09 # param length 9 2348 \x02 # alpn length 2 2349 h2 # alpn value 2350 \x05 # alpn length 5 2351 h3-19 # alpn value 2352 \x00\x04 # key 4 2353 \x00\x04 # param length 4 2354 \xc0\x00\x02\x01 # param value 2356 This last vector has an alpn value with an escaped comma and an 2357 escaped backslash in two presentation formats. 2359 example.com. SVCB 16 foo.example.org. alpn="f\\\\oo\\,bar,h2" 2360 example.com. SVCB 16 foo.example.org. alpn=f\\\092oo\092,bar,h2 2362 \# 35 ( 2363 00 10 ; priority 2364 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target 2365 00 01 ; key 1 2366 00 0c ; param length 12 2367 08 ; alpn length 8 2368 66 5c 6f 6f 2c 62 61 72 ; alpn value 2369 02 ; alpn length 2 2370 68 32 ; alpn value 2371 ) 2373 \x00\x10 # priority 2374 \x03foo\x07example\x03org\x00 # target 2375 \x00\x01 # key 1 2376 \x00\x0c # param length 12 2377 \x08 # alpn length 8 2378 f\oo,bar # alpn value 2379 \x02 # alpn length 2 2380 h2 # alpn value 2382 D.3. Failure cases 2384 In this subsection, example resource records are shown which are not 2385 compliant with this document. The various reasons for non-compliance 2386 are explained with each example. 2388 This example has multiple instances of the same SvcParamKey 2389 Section 2.1. 2391 example.com. SVCB 1 foo.example.com. ( 2392 key123=abc key123=def 2393 ) 2395 In the next examples the SvcParamKeys are missing their values. 2397 example.com. SVCB 1 foo.example.com. mandatory 2398 example.com. SVCB 1 foo.example.com. alpn 2399 example.com. SVCB 1 foo.example.com. port 2400 example.com. SVCB 1 foo.example.com. ipv4hint 2401 example.com. SVCB 1 foo.example.com. ipv6hint 2403 The "no-default-alpn" SvcParamKey value MUST be empty (Section 6.1). 2405 example.com. SVCB 1 foo.example.com. no-default-alpn=abc 2406 In this record a mandatory SvcParam is missing (Section 7). 2408 example.com. SVCB 1 foo.example.com. mandatory=key123 2410 The "mandatory" SvcParamKey MUST not be included in mandatory list 2411 (Section 7). 2413 example.com. SVCB 1 foo.example.com. mandatory=mandatory 2415 Here there are multiple instances of the same SvcParamKey in the 2416 mandatory list (Section 7). 2418 example.com. SVCB 1 foo.example.com. ( 2419 mandatory=key123,key123 key123=abc 2420 ) 2422 Appendix E. Change history 2424 (This section to be removed by the RFC editor.) 2426 * draft-ietf-dnsop-svcb-https-07 2428 - Editorial improvements following AD review. 2430 * draft-ietf-dnsop-svcb-https-06 2432 - Add requirements for HTTPS origins that also use Alt-Svc 2434 - Remove requirement for comma-escaping related to unusual ALPN 2435 values 2437 - Allow resolvers to reject invalid SvcParamValues, with 2438 additional guidance 2440 * draft-ietf-dnsop-svcb-https-05 2442 - Specify interaction with EDNS Client Subnet and Additional 2443 section caching 2445 - Rename "echconfig" to "ech" 2447 - Add a suite of test vectors (both valid and invalid) and more 2448 examples 2450 - Clarify requirements for resolvers' (non-)use of SvcParams 2452 - Clarify guidance regarding default ALPN values 2454 * draft-ietf-dnsop-svcb-https-04 2456 - Simplify the IANA instructions (pure First Come First Served) 2458 - Recommend against publishing chains of >8 aliases 2460 - Clarify requirements for using SVCB with a transport proxy 2462 - Adjust guidance for Port Prefix Naming 2464 - Minor editorial updates 2466 * draft-ietf-dnsop-svcb-https-03 2468 - Simplified escaping of comma-separated values 2470 - Reorganized client requirements 2472 - Added a warning about port filtering for cross-protocol attacks 2474 - Clarified self-consistency rules for SvcParams 2476 - Added a non-normative mapping summary table for HTTPS 2478 * draft-ietf-dnsop-svcb-https-02 2480 - Added a Privacy Considerations section 2482 - Adjusted resolution fallback description 2484 - Clarified status of SvcParams in AliasMode 2486 - Improved advice on zone structuring and use with Alt-Svc 2488 - Improved examples, including a new Multi-CDN example 2490 - Reorganized text on value-list parsing and SvcPriority 2492 - Improved phrasing and other editorial improvements throughout 2494 * draft-ietf-dnsop-svcb-https-01 2496 - Added a "mandatory" SvcParamKey 2498 - Added the ability to indicate that a service does not exist 2500 - Adjusted resolution and ALPN algorithms 2501 - Major terminology revisions for "origin" and CamelCase names 2503 - Revised ABNF 2505 - Include allocated RR type numbers 2507 - Various corrections, explanations, and recommendations 2509 * draft-ietf-dnsop-svcb-https-00 2511 - Rename HTTPSSVC RR to HTTPS RR 2513 - Rename "an SVCB" to "a SVCB" 2515 - Removed "design considerations and open issues" section and 2516 some other "to be removed" text 2518 * draft-ietf-dnsop-svcb-httpssvc-03 2520 - Revised chain length limit requirements 2522 - Revised IANA registry rules for SvcParamKeys 2524 - Require HTTPS clients to implement SNI 2526 - Update terminology for Encrypted ClientHello 2528 - Clarifications: non-default ports, transport proxies, HSTS 2529 procedure, WebSocket behavior, wire format, IP hints, inner/ 2530 outer ClientHello with ECH 2532 - Various textual and ABNF corrections 2534 * draft-ietf-dnsop-svcb-httpssvc-02 2536 - All changes to Alt-Svc have been removed 2538 - Expanded and reorganized examples 2540 - Priority zero is now the definition of AliasForm 2542 - Repeated SvcParamKeys are no longer allowed 2544 - The "=" sign may be omitted in a key=value pair if the value is 2545 also empty 2547 - In the wire format, SvcParamKeys must be in sorted order 2548 - New text regarding how to handle resolution timeouts 2550 - Expanded description of recursive resolver behavior 2552 - Much more precise description of the intended ALPN behavior 2554 - Match the HSTS specification's language on HTTPS enforcement 2556 - Removed 'esniconfig=""' mechanism and simplified ESNI 2557 connection logic 2559 * draft-ietf-dnsop-svcb-httpssvc-01 2561 - Reduce the emphasis on conversion between HTTPSSVC and Alt-Svc 2563 - Make the "untrusted channel" concept more precise. 2565 - Make SvcFieldPriority = 0 the definition of AliasForm, instead 2566 of a requirement. 2568 * draft-ietf-dnsop-svcb-httpssvc-00 2570 - Document an optimization for optimistic pre-connection. (Chris 2571 Wood) 2573 - Relax IP hint handling requirements. (Eric Rescorla) 2575 * draft-nygren-dnsop-svcb-httpssvc-00 2577 - Generalize to an SVCB record, with special-case handling for 2578 Alt-Svc and HTTPS separated out to dedicated sections. 2580 - Split out a separate HTTPSSVC record for the HTTPS use-case. 2582 - Remove the explicit SvcRecordType=0/1 and instead make the 2583 AliasForm vs ServiceForm be implicit. This was based on 2584 feedback recommending against subtyping RR type. 2586 - Remove one optimization. 2588 * draft-nygren-httpbis-httpssvc-03 2590 - Change redirect type for HSTS-style behavior from 302 to 307 to 2591 reduce ambiguities. 2593 * draft-nygren-httpbis-httpssvc-02 2595 - Remove the redundant length fields from the wire format. 2597 - Define a SvcDomainName of "." for SvcRecordType=1 as being the 2598 HTTPSSVC RRNAME. 2600 - Replace "hq" with "h3". 2602 * draft-nygren-httpbis-httpssvc-01 2604 - Fixes of record name. Replace references to "HTTPSVC" with 2605 "HTTPSSVC". 2607 * draft-nygren-httpbis-httpssvc-00 2609 - Initial version 2611 Authors' Addresses 2613 Ben Schwartz 2614 Google 2616 Email: bemasc@google.com 2618 Mike Bishop 2619 Akamai Technologies 2621 Email: mbishop@evequefou.be 2623 Erik Nygren 2624 Akamai Technologies 2626 Email: erik+ietf@nygren.org