idnits 2.17.1 draft-ietf-dnsop-svcb-https-04.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 -- The document date (March 17, 2021) is 1136 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) -- Looks like a reference, but probably isn't: '1' on line 1888 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-09 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-33 ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 8499 (ref. 'DNSTerm') (Obsoleted by RFC 9499) 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: September 18, 2021 E. Nygren 6 Akamai Technologies 7 March 17, 2021 9 Service binding and parameter specification via the DNS (DNS SVCB and 10 HTTPS RRs) 11 draft-ietf-dnsop-svcb-https-04 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 [1]. The most recent 29 working version of the document, open issues, etc. should all be 30 available there. The authors (gratefully) accept pull requests. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 18, 2021. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 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 . . . . . . . . . . . . . . . . . 5 69 1.3. Parameter for Encrypted ClientHello . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 16 89 5. Performance optimizations . . . . . . . . . . . . . . . . . . 17 90 5.1. Optimistic pre-connection and connection reuse . . . . . 17 91 5.2. Generating and using incomplete responses . . . . . . . . 18 92 6. Initial SvcParamKeys . . . . . . . . . . . . . . . . . . . . 18 93 6.1. "alpn" and "no-default-alpn" . . . . . . . . . . . . . . 18 94 6.2. "port" . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 6.3. "echconfig" . . . . . . . . . . . . . . . . . . . . . . . 21 96 6.4. "ipv4hint" and "ipv6hint" . . . . . . . . . . . . . . . . 21 98 7. ServiceMode RR compatibility and mandatory keys . . . . . . . 22 99 8. Using SVCB with HTTPS and HTTP . . . . . . . . . . . . . . . 23 100 8.1. Query names for HTTPS RRs . . . . . . . . . . . . . . . . 23 101 8.2. Relationship to Alt-Svc . . . . . . . . . . . . . . . . . 24 102 8.2.1. ALPN usage . . . . . . . . . . . . . . . . . . . . . 24 103 8.2.2. Untrusted channel . . . . . . . . . . . . . . . . . . 24 104 8.2.3. Cache lifetime . . . . . . . . . . . . . . . . . . . 25 105 8.2.4. Granularity . . . . . . . . . . . . . . . . . . . . . 25 106 8.3. Interaction with Alt-Svc . . . . . . . . . . . . . . . . 25 107 8.4. Requiring Server Name Indication . . . . . . . . . . . . 25 108 8.5. HTTP Strict Transport Security . . . . . . . . . . . . . 26 109 8.6. HTTP-based protocols . . . . . . . . . . . . . . . . . . 26 110 9. SVCB/HTTPS RR parameter for ECH configuration . . . . . . . . 27 111 9.1. Client behavior . . . . . . . . . . . . . . . . . . . . . 27 112 9.2. Deployment considerations . . . . . . . . . . . . . . . . 27 113 10. Zone Structures . . . . . . . . . . . . . . . . . . . . . . . 27 114 10.1. Structuring zones for flexibility . . . . . . . . . . . 28 115 10.2. Structuring zones for performance . . . . . . . . . . . 28 116 10.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 28 117 10.3.1. Protocol enhancements . . . . . . . . . . . . . . . 28 118 10.3.2. Apex aliasing . . . . . . . . . . . . . . . . . . . 29 119 10.3.3. Parameter binding . . . . . . . . . . . . . . . . . 29 120 10.3.4. Multi-CDN . . . . . . . . . . . . . . . . . . . . . 30 121 10.3.5. Non-HTTPS uses . . . . . . . . . . . . . . . . . . . 32 122 11. Interaction with other standards . . . . . . . . . . . . . . 32 123 12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 124 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 125 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 126 14.1. SVCB RRType . . . . . . . . . . . . . . . . . . . . . . 34 127 14.2. HTTPS RRType . . . . . . . . . . . . . . . . . . . . . . 34 128 14.3. New registry for Service Parameters . . . . . . . . . . 34 129 14.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . 34 130 14.3.2. Initial contents . . . . . . . . . . . . . . . . . . 35 131 14.4. Registry updates . . . . . . . . . . . . . . . . . . . . 36 132 15. Acknowledgments and Related Proposals . . . . . . . . . . . . 37 133 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 134 16.1. Normative References . . . . . . . . . . . . . . . . . . 37 135 16.2. Informative References . . . . . . . . . . . . . . . . . 40 136 16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 41 137 Appendix A. Decoding text in zone files . . . . . . . . . . . . 41 138 A.1. Decoding a comma-separated list . . . . . . . . . . . . . 41 139 Appendix B. HTTP Mapping Summary . . . . . . . . . . . . . . . . 42 140 Appendix C. Comparison with alternatives . . . . . . . . . . . . 43 141 C.1. Differences from the SRV RR type . . . . . . . . . . . . 43 142 C.2. Differences from the proposed HTTP record . . . . . . . . 43 143 C.3. Differences from the proposed ANAME record . . . . . . . 43 144 C.4. Comparison with separate RR types for AliasMode and 145 ServiceMode . . . . . . . . . . . . . . . . . . . . . . . 44 147 Appendix D. Change history . . . . . . . . . . . . . . . . . . . 44 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 150 1. Introduction 152 The SVCB ("Service Binding") and HTTPS RRs provide clients with 153 complete instructions for access to a service. This information 154 enables improved performance and privacy by avoiding transient 155 connections to a sub-optimal default server, negotiating a preferred 156 protocol, and providing relevant public keys. 158 For example, when clients need to make a connection to fetch 159 resources associated with an HTTPS URI, they currently resolve only A 160 and/or AAAA records for the origin hostname. This is adequate for 161 services that use basic HTTPS (fixed port, no QUIC, no [ECH]). Going 162 beyond basic HTTPS confers privacy, performance, and operational 163 advantages, but it requires the client to learn additional 164 information, and it is highly desirable to minimize the number of 165 round-trips and lookups required to learn this additional 166 information. 168 The SVCB and HTTPS RRs also help when the operator of a service 169 wishes to delegate operational control to one or more other domains, 170 e.g. delegating the origin "https://example.com" to a service 171 operator endpoint at "svc.example.net". While this case can 172 sometimes be handled by a CNAME, that does not cover all use-cases. 173 CNAME is also inadequate when the service operator needs to provide a 174 bound collection of consistent configuration parameters through the 175 DNS (such as network location, protocol, and keying information). 177 This document first describes the SVCB RR as a general-purpose 178 resource record that can be applied directly and efficiently to a 179 wide range of services (Section 2). The HTTPS RR is then defined as 180 a special case of SVCB that improves efficiency and convenience for 181 use with HTTPS (Section 8) by avoiding the need for an Attrleaf label 182 [Attrleaf] (Section 8.1). Other protocols with similar needs may 183 follow the pattern of HTTPS and assign their own SVCB-compatible RR 184 types. 186 All behaviors described as applying to the SVCB RR also apply to the 187 HTTPS RR unless explicitly stated otherwise. Section 8 describes 188 additional behaviors specific to the HTTPS RR. Apart from Section 8 189 and introductory examples, much of this document refers only to the 190 SVCB RR, but those references should be taken to apply to SVCB, 191 HTTPS, and any future SVCB-compatible RR types. 193 The SVCB RR has two modes: 1) "AliasMode" simply delegates 194 operational control for a resource; 2) "ServiceMode" binds together 195 configuration information for a service endpoint. ServiceMode 196 provides additional key=value parameters within each RDATA set. 198 1.1. Goals of the SVCB RR 200 The goal of the SVCB RR is to allow clients to resolve a single 201 additional DNS RR in a way that: 203 o Provides alternative endpoints that are authoritative for the 204 service, along with parameters associated with each of these 205 endpoints. 207 o Does not assume that all alternative endpoints have the same 208 parameters or capabilities, or are even operated by the same 209 entity. This is important as DNS does not provide any way to tie 210 together multiple RRs for the same name. For example, if 211 www.example.com is a CNAME alias that switches between one of 212 three CDNs or hosting environments, successive queries for that 213 name may return records that correspond to different environments. 215 o Enables CNAME-like functionality at a zone apex (such as 216 "example.com") for participating protocols, and generally enables 217 delegation of operational authority for an origin within the DNS 218 to an alternate name. 220 Additional goals specific to HTTPS RRs and the HTTPS use-case 221 include: 223 o Connect directly to HTTP3 (QUIC transport) alternative endpoints 224 [HTTP3] 226 o Obtain the Encrypted ClientHello [ECH] keys associated with an 227 alternative endpoint 229 o Support non-default TCP and UDP ports 231 o Enable SRV-like benefits (e.g. apex delegation, as mentioned 232 above) for HTTP(S), where SRV [SRV] has not been widely adopted 234 o Provide an HSTS-like indication [HSTS] signaling that the HTTPS 235 scheme should be used instead of HTTP for this request (see 236 Section 8.5). 238 1.2. Overview of the SVCB RR 240 This subsection briefly describes the SVCB RR in a non-normative 241 manner. (As mentioned above, this all applies equally to the HTTPS 242 RR which shares the same encoding, format, and high-level semantics.) 243 The SVCB RR has two modes: AliasMode, which aliases a name to another 244 name, and ServiceMode, which provides connection information bound to 245 a service endpoint domain. Placing both forms in a single RR type 246 allows clients to fetch the relevant information with a single query. 248 The SVCB RR has two mandatory fields and one optional. The fields 249 are: 251 1. SvcPriority: The priority of this record (relative to others, 252 with lower values preferred). A value of 0 indicates AliasMode. 253 (Described in Section 2.4.1.) 255 2. TargetName: The domain name of either the alias target (for 256 AliasMode) or the alternative endpoint (for ServiceMode). 258 3. SvcParams (optional): A list of key=value pairs describing the 259 alternative endpoint at TargetName (only used in ServiceMode and 260 otherwise ignored). Described in Section 2.1. 262 Cooperating DNS recursive resolvers will perform subsequent record 263 resolution (for SVCB, A, and AAAA records) and return them in the 264 Additional Section of the response. Clients either use responses 265 included in the additional section returned by the recursive resolver 266 or perform necessary SVCB, A, and AAAA record resolutions. DNS 267 authoritative servers can attach in-bailiwick SVCB, A, AAAA, and 268 CNAME records in the Additional Section to responses for a SVCB 269 query. 271 In ServiceMode, the SvcParams of the SVCB RR provide an extensible 272 data model for describing alternative endpoints that are 273 authoritative for the origin, along with parameters associated with 274 each of these alternative endpoints. 276 For the HTTPS use-case, the HTTPS RR enables many of the benefits of 277 Alt-Svc [AltSvc] without waiting for a full HTTP connection 278 initiation (multiple roundtrips) before learning of the preferred 279 alternative, and without necessarily revealing the user's intended 280 destination to all entities along the network path. 282 1.3. Parameter for Encrypted ClientHello 284 This document also defines a parameter for Encrypted ClientHello 285 [ECH] keys. See Section 9. 287 1.4. Terminology 289 Our terminology is based on the common case where the SVCB record is 290 used to access a resource identified by a URI whose "authority" field 291 contains a DNS hostname as the "host". 293 o The "service" is the information source identified by the 294 "authority" and "scheme" of the URI, capable of providing access 295 to the resource. For HTTPS URIs, the "service" corresponds to an 296 HTTPS "origin" [RFC6454]. 298 o The "service name" is the "host" portion of the authority. 300 o The "authority endpoint" is the authority's hostname and a port 301 number implied by the scheme or specified in the URI. 303 o An "alternative endpoint" is a hostname, port number, and other 304 associated instructions to the client on how to reach an instance 305 of service. 307 Additional DNS terminology intends to be consistent with [DNSTerm]. 309 SVCB is a contraction of "service binding". The SVCB RR, HTTPS RR, 310 and future RR types that share SVCB's format and registry are 311 collectively known as SVCB-compatible RR types. 313 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 314 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 315 "OPTIONAL" in this document are to be interpreted as described in BCP 316 14 [RFC2119] [RFC8174] when, and only when, they appear in all 317 capitals, as shown here. 319 2. The SVCB record type 321 The SVCB DNS resource record (RR) type (RR type 64) is used to locate 322 alternative endpoints for a service. 324 The algorithm for resolving SVCB records and associated address 325 records is specified in Section 3. 327 Other SVCB-compatible resource record types can also be defined as- 328 needed. In particular, the HTTPS RR (RR type 65) provides special 329 handling for the case of "https" origins as described in Section 8. 331 SVCB RRs are extensible by a list of SvcParams, which are pairs 332 consisting of a SvcParamKey and a SvcParamValue. Each SvcParamKey 333 has a presentation name and a registered number. Values are in a 334 format specific to the SvcParamKey. Their definition should specify 335 both their presentation format and wire encoding (e.g., domain names, 336 binary data, or numeric values). The initial SvcParamKeys and 337 formats are defined in Section 6. 339 2.1. Zone file presentation format 341 The presentation format of the record is: 343 Name TTL IN SVCB SvcPriority TargetName SvcParams 345 The SVCB record is defined specifically within the Internet ("IN") 346 Class ([RFC1035]). 348 SvcPriority is a number in the range 0-65535, TargetName is a 349 "" ([RFC1035] Section 5.1), and the SvcParams are a 350 whitespace-separated list, with each SvcParam consisting of a 351 SvcParamKey=SvcParamValue pair or a standalone SvcParamKey. 352 SvcParamKeys are subject to IANA control (Section 14.3). 354 Each SvcParamKey SHALL appear at most once in the SvcParams. In 355 presentation format, SvcParamKeys are lower-case alphanumeric 356 strings. Key names should contain 1-63 characters from the ranges 357 "a"-"z", "0"-"9", and "-". In ABNF [RFC5234], 359 alpha-lc = %x61-7A ; a-z 360 SvcParamKey = 1*63(alpha-lc / DIGIT / "-") 361 SvcParam = SvcParamKey ["=" SvcParamValue] 362 SvcParamValue = char-string 363 value = *OCTET 365 The SvcParamValue is parsed using the character-string decoding 366 algorithm (Appendix A), producing a "value". The "value" is then 367 validated and converted into wire-format in a manner specific to each 368 key. 370 When the "=" is omitted, the "value" is interpreted as empty. 372 Unrecognized keys are represented in presentation format as 373 "keyNNNNN" where NNNNN is the numeric value of the key type without 374 leading zeros. A SvcParam in this form SHALL be parsed as specified 375 above, and the decoded "value" SHALL be used as its wire format 376 encoding. 378 For some SvcParamKeys, the "value" corresponds to a list or set of 379 items. Presentation formats for such keys SHOULD use a comma- 380 separated list (Appendix A.1). 382 SvcParams in presentation format MAY appear in any order, but keys 383 MUST NOT be repeated. 385 2.2. RDATA wire format 387 The RDATA for the SVCB RR consists of: 389 o a 2 octet field for SvcPriority as an integer in network byte 390 order. 392 o the uncompressed, fully-qualified TargetName, represented as a 393 sequence of length-prefixed labels as in Section 3.1 of [RFC1035]. 395 o the SvcParams, consuming the remainder of the record (so smaller 396 than 65535 octets and constrained by the RDATA and DNS message 397 sizes). 399 When the list of SvcParams is non-empty (ServiceMode), it contains a 400 series of SvcParamKey=SvcParamValue pairs, represented as: 402 o a 2 octet field containing the SvcParamKey as an integer in 403 network byte order. (See Section 14.3.2 for the defined values.) 405 o a 2 octet field containing the length of the SvcParamValue as an 406 integer between 0 and 65535 in network byte order (but constrained 407 by the RDATA and DNS message sizes). 409 o an octet string of this length whose contents are in a format 410 determined by the SvcParamKey. 412 SvcParamKeys SHALL appear in increasing numeric order. 414 Clients MUST consider an RR malformed if: 416 o the end of the RDATA occurs within a SvcParam. 418 o SvcParamKeys are not in strictly increasing numeric order. 420 o the SvcParamValue for an SvcParamKey does not have the expected 421 format. 423 Note that the second condition implies that there are no duplicate 424 SvcParamKeys. 426 If any RRs are malformed, the client MUST reject the entire RRSet and 427 fall back to non-SVCB connection establishment. 429 2.3. SVCB query names 431 When querying the SVCB RR, a service is translated into a QNAME by 432 prepending the service name with a label indicating the scheme, 433 prefixed with an underscore, resulting in a domain name like 434 "_examplescheme.api.example.com.". This follows the Attrleaf naming 435 pattern [Attrleaf], so the scheme MUST be registered appropriately 436 with IANA (see Section 11). 438 Protocol mapping documents MAY specify additional underscore-prefixed 439 labels to be prepended. For schemes that specify a port 440 (Section 3.2.3 of [URI]), one reasonable possibility is to prepend 441 the indicated port number if a non-default port number is specified. 442 We term this behavior "Port Prefix Naming", and use it in the 443 examples throughout this document. 445 See Section 8.1 for the HTTPS RR behavior. 447 When a prior CNAME or SVCB record has aliased to a SVCB record, each 448 RR shall be returned under its own owner name. 450 Note that none of these forms alter the origin or authority for 451 validation purposes. For example, TLS clients MUST continue to 452 validate TLS certificates for the original service name. 454 As an example, the owner of example.com could publish this record: 456 _8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net. 458 to indicate that "foo://api.example.com:8443" is aliased to 459 "svc4.example.net". The owner of example.net, in turn, could publish 460 this record: 462 svc4.example.net. 7200 IN SVCB 3 svc4.example.net. ( 463 alpn="bar" port="8004" echconfig="..." ) 465 to indicate that these services are served on port number 8004, which 466 supports the protocol "bar" and its associated transport in addition 467 to the default transport protocol for "foo://". 469 (Parentheses are used to ignore a line break ([RFC1035] 470 Section 5.1).) 472 2.4. Interpretation 473 2.4.1. SvcPriority 475 When SvcPriority is 0 the SVCB record is in AliasMode 476 (Section 2.4.2). Otherwise, it is in ServiceMode (Section 2.4.3). 478 Within a SVCB RRSet, all RRs SHOULD have the same Mode. If an RRSet 479 contains a record in AliasMode, the recipient MUST ignore any 480 ServiceMode records in the set. 482 RRSets are explicitly unordered collections, so the SvcPriority field 483 is used to impose an ordering on SVCB RRs. SVCB RRs with a smaller 484 SvcPriority value SHOULD be given preference over RRs with a larger 485 SvcPriority value. 487 When receiving an RRSet containing multiple SVCB records with the 488 same SvcPriority value, clients SHOULD apply a random shuffle within 489 a priority level to the records before using them, to ensure uniform 490 load-balancing. 492 2.4.2. AliasMode 494 In AliasMode, the SVCB record aliases a service to a TargetName. 495 SVCB RRSets SHOULD only have a single resource record in AliasMode. 496 If multiple are present, clients or recursive resolvers SHOULD pick 497 one at random. 499 The primary purpose of AliasMode is to allow aliasing at the zone 500 apex, where CNAME is not allowed. In AliasMode, the TargetName will 501 be the name of a domain that resolves to SVCB (or other SVCB- 502 compatible record such as HTTPS), AAAA, and/or A records. The 503 TargetName SHOULD NOT be equal to the owner name, as this would 504 result in a loop. 506 In AliasMode, records SHOULD NOT include any SvcParams, and 507 recipients MUST ignore any SvcParams that are present. 509 For example, the operator of foo://example.com:8080 could point 510 requests to a service operating at foosvc.example.net by publishing: 512 _8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net. 514 Using AliasMode maintains a separation of concerns: the owner of 515 foosvc.example.net can add or remove ServiceMode SVCB records without 516 requiring a corresponding change to example.com. Note that if 517 foosvc.example.net promises to always publish a SVCB record, this 518 AliasMode record can be replaced by a CNAME, which would likely 519 improve performance. 521 AliasMode is especially useful for SVCB-compatible RR types that do 522 not require an underscore prefix, such as the HTTPS RR type. For 523 example, the operator of https://example.com could point requests to 524 a server at svc.example.net by publishing this record at the zone 525 apex: 527 example.com. 3600 IN HTTPS 0 svc.example.net. 529 Note that the SVCB record's owner name MAY be the canonical name of a 530 CNAME record, and the TargetName MAY be the owner of a CNAME record. 531 Clients and recursive resolvers MUST follow CNAMEs as normal. 533 To avoid unbounded alias chains, clients and recursive resolvers MUST 534 impose a limit on the total number of SVCB aliases they will follow 535 for each resolution request. This limit MUST NOT be zero, i.e. 536 implementations MUST be able to follow at least one AliasMode record. 537 The exact value of this limit is left to implementations. 539 For compatibility and performance, zone owners SHOULD NOT configure 540 their zones to require following multiple AliasMode records. 542 As legacy clients will not know to use this record, service operators 543 will likely need to retain fallback AAAA and A records alongside this 544 SVCB record, although in a common case the target of the SVCB record 545 might offer better performance, and therefore would be preferable for 546 clients implementing this specification to use. 548 AliasMode records only apply to queries for the specific RR type. 549 For example, a SVCB record cannot alias to an HTTPS record, nor vice- 550 versa. 552 2.4.3. ServiceMode 554 In ServiceMode, the TargetName and SvcParams within each resource 555 record associate an alternative endpoint for the service with its 556 connection parameters. 558 Each protocol scheme that uses SVCB MUST define a protocol mapping 559 that explains how SvcParams are applied for connections of that 560 scheme. Unless specified otherwise by the protocol mapping, clients 561 MUST ignore any SvcParam that they do not recognize. 563 Some SvcParams impose requirements on other SvcParams in the RR. A 564 ServiceMode RR is called "self-consistent" if its SvcParams all 565 comply with each others' requirements. Zone-file implementations 566 SHOULD enforce self-consistency. Clients MUST reject any RR whose 567 recognized SvcParams are not self-consistent, and MAY reject the 568 entire RRSet. 570 2.5. Special handling of "." in TargetName 572 If TargetName has the value "." (represented in the wire format as a 573 zero-length label), special rules apply. 575 2.5.1. AliasMode 577 For AliasMode SVCB RRs, a TargetName of "." indicates that the 578 service is not available or does not exist. This indication is 579 advisory: clients encountering this indication MAY ignore it and 580 attempt to connect without the use of SVCB. 582 2.5.2. ServiceMode 584 For ServiceMode SVCB RRs, if TargetName has the value ".", then the 585 owner name of this record MUST be used as the effective TargetName. 587 For example, in the following example "svc2.example.net" is the 588 effective TargetName: 590 example.com. 7200 IN HTTPS 0 svc.example.net. 591 svc.example.net. 7200 IN CNAME svc2.example.net. 592 svc2.example.net. 7200 IN HTTPS 1 . port=8002 echconfig="..." 593 svc2.example.net. 300 IN A 192.0.2.2 594 svc2.example.net. 300 IN AAAA 2001:db8::2 596 3. Client behavior 598 "SVCB resolution" is the process of enumerating the priority-ordered 599 endpoints for a service, as performed by the client. SVCB resolution 600 is implemented as follows: 602 1. Let $QNAME be the service name plus appropriate prefixes for the 603 scheme (see Section 2.3). 605 2. Issue a SVCB query for $QNAME. 607 3. If an AliasMode SVCB record is returned for $QNAME (after 608 following CNAMEs as normal), set $QNAME to its TargetName 609 (without additional prefixes) and loop back to step 2, subject to 610 chain length limits and loop detection heuristics (see 611 Section 3.1). 613 4. If one or more "compatible" (Section 7) ServiceMode records are 614 returned, these represent the alternative endpoints. 616 5. Otherwise, SVCB resolution has failed, and the list of known 617 endpoints is empty. 619 This procedure does not rely on any recursive or authoritative DNS 620 server to comply with this specification or have any awareness of 621 SVCB. 623 Once SVCB resolution has concluded, the client proceeds with 624 connection establishment. Clients SHOULD try higher-priority 625 alternatives first, with fallback to lower-priority alternatives. 626 Clients issue AAAA and/or A queries for the selected TargetName, and 627 MAY choose between them using an approach such as Happy Eyeballs 628 [HappyEyeballsV2]. 630 A client is called "SVCB-optional" if it can connect without the use 631 of ServiceMode records, and "SVCB-reliant" otherwise. Clients for 632 pre-existing protocols (e.g. HTTPS) SHALL implement SVCB-optional 633 behavior (except as noted in Section 3.1 and Section 9.1). 635 SVCB-optional clients SHOULD issue in parallel any other DNS queries 636 that might be needed for connection establishment. SVCB-optional 637 clients SHALL append an alternative endpoint consisting of the final 638 value of $QNAME, the authority endpoint's port number, and no 639 SvcParams, to the list of alternative endpoints, which is attempted 640 before falling back to non-SVCB connection modes. This ensures that 641 SVCB-optional clients will make use of an AliasMode record whose 642 TargetName has A and/or AAAA records but no SVCB records. 644 Some important optimizations are discussed in Section 5 to avoid 645 additional latency in comparison to ordinary AAAA/A lookups. 647 3.1. Handling resolution failures 649 If SVCB resolution fails due to a SERVFAIL error, transport error, or 650 timeout, and DNS exchanges between the client and the recursive 651 resolver are cryptographically protected (e.g. using TLS [DoT] or 652 HTTPS [DoH]), a SVCB-optional client SHOULD abandon the connection 653 attempt like a SVCB-reliant client would. Otherwise, an active 654 attacker could mount a downgrade attack by denying the user access to 655 the SvcParams. 657 A SERVFAIL error can occur if the domain is DNSSEC-signed, the 658 recursive resolver is DNSSEC-validating, and the attacker is between 659 the recursive resolver and the authoritative DNS server. A transport 660 error or timeout can occur if an active attacker between the client 661 and the recursive resolver is selectively dropping SVCB queries or 662 responses, based on their size or other observable patterns. 664 Similarly, if the client enforces DNSSEC validation on A/AAAA 665 responses, it SHOULD terminate the connection if a SVCB response 666 fails to validate. 668 If the client is unable to complete SVCB resolution due to its chain 669 length limit, the client SHOULD fall back to the authority endpoint, 670 as if the origin's SVCB record did not exist. 672 3.2. Clients using a Proxy 674 Clients using a domain-oriented transport proxy like HTTP CONNECT 675 ([RFC7231] Section 4.3.6) or SOCKS5 ([RFC1928]) have the option to 676 use named destinations, in which case the client does not perform any 677 A or AAAA queries for destination domains. If the client is using 678 named destinations with a proxy that does not provide SVCB query 679 capability (e.g. through an affiliated DNS resolver), the client 680 would have to perform SVCB resolution separately, likely disclosing 681 the destinations to additional parties. Clients that support such 682 proxies SHOULD arrange for a separate SVCB resolution procedure with 683 appropriate privacy properties, or disable SVCB resolution entirely 684 if SVCB-optional. 686 If the client does use SVCB and named destinations, the client SHOULD 687 follow the standard SVCB resolution process, selecting the smallest- 688 SvcPriority option that is compatible with the client and the proxy. 689 When connecting using a SVCB record, clients MUST provide the final 690 TargetName and port to the proxy, which will perform any required A 691 and AAAA lookups. 693 Providing the proxy with the final TargetName has several benefits: 695 o It allows the client to use the SvcParams, if present, which is 696 only usable with a specific TargetName. The SvcParams may include 697 information that enhances performance (e.g. alpn) and privacy 698 (e.g. echconfig). 700 o It allows the service to delegate the apex domain. 702 o It allows the proxy to select between IPv4 and IPv6 addresses for 703 the server according to its configuration, and receive addresses 704 based on its network geolocation. 706 4. DNS Server Behavior 708 4.1. Authoritative servers 710 When replying to a SVCB query, authoritative DNS servers SHOULD 711 return A, AAAA, and SVCB records in the Additional Section for any 712 in-bailiwick TargetNames. If the zone is signed, the server SHOULD 713 also include positive or negative DNSSEC responses for these records 714 in the Additional section. 716 4.2. Recursive resolvers 718 Recursive resolvers that are aware of SVCB SHOULD help the client to 719 execute the procedure in Section 3 with minimum overall latency, by 720 incorporating additional useful information into the response. For 721 the initial SVCB record query, this is just the normal response 722 construction process (i.e. unknown RR type resolution under 723 [RFC3597]). For followup resolutions performed during this 724 procedure, we define incorporation as adding all useful RRs from the 725 response to the Additional section without altering the response 726 code. 728 Upon receiving a SVCB query, recursive resolvers SHOULD start with 729 the standard resolution procedure, and then follow this procedure to 730 construct the full response to the stub resolver: 732 1. Incorporate the results of SVCB resolution. If the chain length 733 limit has been reached, terminate successfully (i.e. a NOERROR 734 response). 736 2. If any of the resolved SVCB records are in AliasMode, choose one 737 of them at random, and resolve SVCB, A, and AAAA records for its 738 TargetName. 740 * If any SVCB records are resolved, go to step 1. 742 * Otherwise, incorporate the results of A and AAAA resolution, 743 and terminate. 745 3. All the resolved SVCB records are in ServiceMode. Resolve A and 746 AAAA queries for each TargetName (or for the owner name if 747 TargetName is "."), incorporate all the results, and terminate. 749 In this procedure, "resolve" means the resolver's ordinary recursive 750 resolution procedure, as if processing a query for that RRSet. This 751 includes following any aliases that the resolver would ordinarily 752 follow (e.g. CNAME, DNAME [DNAME]). 754 See Section 2.4.2 for additional safeguards for recursive resolvers 755 to implement to mitigate loops. 757 See Section 5.2 for possible optimizations of this procedure. 759 4.3. General requirements 761 Recursive resolvers SHOULD treat the SvcParams portion of the SVCB RR 762 as opaque and SHOULD NOT try to alter their behavior based on its 763 contents. 765 When responding to a query that includes the DNSSEC OK bit 766 ([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers 767 MUST accompany each RRSet in the Additional section with the same 768 DNSSEC-related records that they would send when providing that RRSet 769 as an Answer (e.g. RRSIG, NSEC, NSEC3). 771 5. Performance optimizations 773 For optimal performance (i.e. minimum connection setup time), clients 774 SHOULD implement a client-side DNS cache. Responses in the 775 Additional section of a SVCB response SHOULD be placed in cache 776 before performing any followup queries. With this behavior, and 777 conforming DNS servers, using SVCB does not add network latency to 778 connection setup. 780 To improve performance when using a non-conforming recursive 781 resolver, clients SHOULD issue speculative A and/or AAAA queries in 782 parallel with each SVCB query, based on a predicted value of 783 TargetName (see Section 10.2). 785 After a ServiceMode RRSet is received, clients MAY try more than one 786 option in parallel, and MAY prefetch A and AAAA records for multiple 787 TargetNames. 789 5.1. Optimistic pre-connection and connection reuse 791 If an address response arrives before the corresponding SVCB 792 response, the client MAY initiate a connection as if the SVCB query 793 returned NODATA, but MUST NOT transmit any information that could be 794 altered by the SVCB response until it arrives. For example, a TLS 795 ClientHello can be altered by the "echconfig" value of a SVCB 796 response (Section 6.3). Clients implementing this optimization 797 SHOULD wait for 50 milliseconds before starting optimistic pre- 798 connection, as per the guidance in [HappyEyeballsV2]. 800 A SVCB record is consistent with a connection if the client would 801 attempt an equivalent connection when making use of that record. If 802 a SVCB record is consistent with an active or in-progress connection 803 C, the client MAY prefer that record and use C as its connection. 804 For example, suppose the client receives this SVCB RRSet for a 805 protocol that uses TLS over TCP: 807 _1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. ( 808 echconfig="111..." ipv6hint=2001:db8::1 port=1234 ) 809 SVCB 2 svc2.example.net. ( 810 echconfig="222..." ipv6hint=2001:db8::2 port=1234 ) 812 If the client has an in-progress TCP connection to 813 "[2001:db8::2]:1234", it MAY proceed with TLS on that connection 814 using "echconfig="222..."", even though the other record in the RRSet 815 has higher priority. 817 If none of the SVCB records are consistent with any active or in- 818 progress connection, clients proceed with connection establishment as 819 described in Section 3. 821 5.2. Generating and using incomplete responses 823 When following the procedure in Section 4.2, recursive resolvers MAY 824 terminate the procedure early and produce a reply that omits some of 825 the associated RRSets. This is REQUIRED when the chain length limit 826 is reached (Section 4.2 step 1), but might also be appropriate when 827 the maximum response size is reached, or when responding before fully 828 chasing dependencies would improve performance. When omitting 829 certain RRSets, recursive resolvers SHOULD prioritize information for 830 smaller-SvcPriority records. 832 As discussed in Section 3, clients MUST be able to fetch additional 833 information that is required to use a SVCB record, if it is not 834 included in the initial response. As a performance optimization, if 835 some of the SVCB records in the response can be used without 836 requiring additional DNS queries, the client MAY prefer those 837 records, regardless of their priorities. 839 6. Initial SvcParamKeys 841 A few initial SvcParamKeys are defined here. These keys are useful 842 for HTTPS, and most are applicable to other protocols as well. Each 843 new protocol mapping document MUST specify which keys are applicable 844 and safe to use. Protocol mappings MAY alter the interpretation of 845 SvcParamKeys but MUST NOT alter their presentation or wire formats. 847 6.1. "alpn" and "no-default-alpn" 849 The "alpn" and "no-default-alpn" SvcParamKeys together indicate the 850 set of Application Layer Protocol Negotiation (ALPN) protocol 851 identifiers [ALPN] and associated transport protocols supported by 852 this service endpoint. 854 As with Alt-Svc [AltSvc], the ALPN protocol identifier is used to 855 identify the application protocol and associated suite of protocols 856 supported by the endpoint (the "protocol suite"). Clients filter the 857 set of ALPN identifiers to match the protocol suites they support, 858 and this informs the underlying transport protocol used (such as 859 QUIC-over-UDP or TLS-over-TCP). 861 ALPNs are identified by their registered "Identification Sequence" 862 ("alpn-id"), which is a sequence of 1-255 octets. 864 alpn-id = 1*255OCTET 866 The presentation "value" SHALL be a comma-separated list 867 (Appendix A.1) of one or more "alpn-id"s. 869 The wire format value for "alpn" consists of at least one "alpn-id" 870 prefixed by its length as a single octet, and these length-value 871 pairs are concatenated to form the SvcParamValue. These pairs MUST 872 exactly fill the SvcParamValue; otherwise, the SvcParamValue is 873 malformed. 875 For "no-default-alpn", the presentation and wire format values MUST 876 be empty. When "no-default-alpn" is specified in an RR, "alpn" must 877 also be specified in order for the RR to be "self-consistent" 878 (Section 2.4.3). 880 Each scheme that uses this SvcParamKey defines a "default set" of 881 supported ALPNs, which SHOULD NOT be empty. To determine the set of 882 protocol suites supported by an endpoint (the "SVCB ALPN set"), the 883 client adds the default set to the list of "alpn-id"s unless the "no- 884 default-alpn" SvcParamKey is present. The presence of an ALPN 885 protocol in the SVCB ALPN set indicates that this service endpoint, 886 described by TargetName and the other parameters (e.g. "port") offers 887 service with the protocol suite associated with this ALPN protocol. 889 ALPN protocol names that do not uniquely identify a protocol suite 890 (e.g. an Identification Sequence that can be used with both TLS and 891 DTLS) are not compatible with this SvcParamKey and MUST NOT be 892 included in the SVCB ALPN set. 894 To establish a connection to the endpoint, clients MUST 896 1. Let SVCB-ALPN-Intersection be the set of protocols in the SVCB 897 ALPN set that the client supports. 899 2. Let Intersection-Transports be the set of transports (e.g. TLS, 900 DTLS, QUIC) implied by the protocols in SVCB-ALPN-Intersection. 902 3. For each transport in Intersection-Transports, construct a 903 ProtocolNameList containing the Identification Sequences of all 904 the client's supported ALPN protocols for that transport, without 905 regard to the SVCB ALPN set. 907 For example, if the SVCB ALPN set is ["http/1.1", "h3"], and the 908 client supports HTTP/1.1, HTTP/2, and HTTP/3, the client could 909 attempt to connect using TLS over TCP with a ProtocolNameList of 910 ["http/1.1", "h2"], and could also attempt a connection using QUIC, 911 with a ProtocolNameList of ["h3"]. 913 Once the client has constructed a ClientHello, protocol negotiation 914 in that handshake proceeds as specified in [ALPN], without regard to 915 the SVCB ALPN set. 917 With this procedure in place, an attacker who can modify DNS and 918 network traffic can prevent a successful transport connection, but 919 cannot otherwise interfere with ALPN protocol selection. This 920 procedure also ensures that each ProtocolNameList includes at least 921 one protocol from the SVCB ALPN set. 923 Clients SHOULD NOT attempt connection to a service endpoint whose 924 SVCB ALPN set does not contain any supported protocols. To ensure 925 consistency of behavior, clients MAY reject the entire SVCB RRSet and 926 fall back to basic connection establishment if all of the RRs 927 indicate "no-default-alpn", even if connection could have succeeded 928 using a non-default alpn. 930 For compatibility with clients that require default transports, zone 931 operators SHOULD ensure that at least one RR in each RRSet supports 932 the default transports. 934 6.2. "port" 936 The "port" SvcParamKey defines the TCP or UDP port that should be 937 used to reach this alternative endpoint. If this key is not present, 938 clients SHALL use the authority endpoint's port number. 940 The presentation "value" of the SvcParamValue is a single decimal 941 integer between 0 and 65535 in ASCII. Any other "value" (e.g. an 942 empty value) is a syntax error. To enable simpler parsing, this 943 SvcParam MUST NOT contain escape sequences. 945 The wire format of the SvcParamValue is the corresponding 2 octet 946 numeric value in network byte order. 948 If a port-restricting firewall is in place between some client and 949 the service endpoint, changing the port number might cause that 950 client to lose access to the service, so operators should exercise 951 caution when using this SvcParamKey to specify a non-default port. 953 6.3. "echconfig" 955 The SvcParamKey to enable Encrypted ClientHello (ECH) is "echconfig". 956 Its value is defined in Section 9. It is applicable to most TLS- 957 based protocols. 959 When publishing a record containing an "echconfig" parameter, the 960 publisher MUST ensure that all IP addresses of TargetName correspond 961 to servers that have access to the corresponding private key or are 962 authoritative for the public name. (See Section 7.2.2 of [ECH] for 963 more details about the public name.) This yields an anonymity set of 964 cardinality equal to the number of ECH-enabled server domains 965 supported by a given client-facing server. Thus, even with an 966 encrypted ClientHello, an attacker who can enumerate the set of ECH- 967 enabled domains supported by a client-facing server can guess the 968 correct SNI with probability at least 1/K, where K is the size of 969 this ECH-enabled server anonymity set. This probability may be 970 increased via traffic analysis or other mechanisms. 972 6.4. "ipv4hint" and "ipv6hint" 974 The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients 975 MAY use to reach the service. If A and AAAA records for TargetName 976 are locally available, the client SHOULD ignore these hints. 977 Otherwise, clients SHOULD perform A and/or AAAA queries for 978 TargetName as in Section 3, and clients SHOULD use the IP address in 979 those responses for future connections. Clients MAY opt to terminate 980 any connections using the addresses in hints and instead switch to 981 the addresses in response to the TargetName query. Failure to use A 982 and/or AAAA response addresses could negatively impact load balancing 983 or other geo-aware features and thereby degrade client performance. 985 The presentation "value" SHALL be a comma-separated list 986 (Appendix A.1) of one or more IP addresses of the appropriate family 987 in standard textual format [RFC5952]. To enable simpler parsing, 988 this SvcParamValue MUST NOT contain escape sequences. 990 The wire format for each parameter is a sequence of IP addresses in 991 network byte order. Like an A or AAAA RRSet, the list of addresses 992 represents an unordered collection, and clients SHOULD pick addresses 993 to use in a random order. An empty list of addresses is invalid. 995 When selecting between IPv4 and IPv6 addresses to use, clients may 996 use an approach such as Happy Eyeballs [HappyEyeballsV2]. When only 997 "ipv4hint" is present, IPv6-only clients may synthesize IPv6 998 addresses as specified in [RFC7050] or ignore the "ipv4hint" key and 999 wait for AAAA resolution (Section 3). Recursive resolvers MUST NOT 1000 perform DNS64 ([RFC6147]) on parameters within a SVCB record. For 1001 best performance, server operators SHOULD include an "ipv6hint" 1002 parameter whenever they include an "ipv4hint" parameter. 1004 These parameters are intended to minimize additional connection 1005 latency when a recursive resolver is not compliant with the 1006 requirements in Section 4, and SHOULD NOT be included if most clients 1007 are using compliant recursive resolvers. When TargetName is the 1008 origin hostname or the owner name (which can be written as "."), 1009 server operators SHOULD NOT include these hints, because they are 1010 unlikely to convey any performance benefit. 1012 7. ServiceMode RR compatibility and mandatory keys 1014 In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the 1015 RR will not function correctly for clients that ignore this 1016 SvcParamKey. Each SVCB protocol mapping SHOULD specify a set of keys 1017 that are "automatically mandatory", i.e. mandatory if they are 1018 present in an RR. The SvcParamKey "mandatory" is used to indicate 1019 any mandatory keys for this RR, in addition to any automatically 1020 mandatory keys that are present. 1022 A ServiceMode RR is considered "compatible" with a client if the 1023 client recognizes all the mandatory keys, and their values indicate 1024 that successful connection establishment is possible. If the SVCB 1025 RRSet contains no compatible RRs, the client will generally act as if 1026 the RRSet is empty. 1028 The presentation "value" SHALL be a comma-separated list 1029 (Appendix A.1) of one or more valid SvcParamKeys, either by their 1030 registered name or in the unknown-key format (Section 2.1). Keys MAY 1031 appear in any order, but MUST NOT appear more than once. For self- 1032 consistency (Section 2.4.3), listed keys MUST also appear in the 1033 SvcParams. 1035 To enable simpler parsing, this SvcParamValue MUST NOT contain escape 1036 sequences. 1038 For example, the following is a valid list of SvcParams: 1040 echconfig=... key65333=ex1 key65444=ex2 mandatory=key65444,echconfig 1042 In wire format, the keys are represented by their numeric values in 1043 network byte order, concatenated in ascending order. 1045 This SvcParamKey is always automatically mandatory, and MUST NOT 1046 appear in its own value-list. Other automatically mandatory keys 1047 SHOULD NOT appear in the list either. (Including them wastes space 1048 and otherwise has no effect.) 1050 8. Using SVCB with HTTPS and HTTP 1052 Use of any protocol with SVCB requires a protocol-specific mapping 1053 specification. This section specifies the mapping for HTTPS and 1054 HTTP. 1056 To enable special handling for the HTTPS and HTTP use-cases, the 1057 HTTPS RR type is defined as a SVCB-compatible RR type, specific to 1058 the https and http schemes. Clients MUST NOT perform SVCB queries or 1059 accept SVCB responses for "https" or "http" schemes. 1061 The HTTPS RR wire format and presentation format are identical to 1062 SVCB, and both share the SvcParamKey registry. SVCB semantics apply 1063 equally to HTTPS RRs unless specified otherwise. The presentation 1064 format of the record is: 1066 Name TTL IN HTTPS SvcPriority TargetName SvcParams 1068 As with SVCB, the record is defined specifically within the Internet 1069 ("IN") Class [RFC1035]. 1071 All the SvcParamKeys defined in Section 6 are permitted for use in 1072 HTTPS RRs. The default set of ALPN IDs is the single value 1073 "http/1.1". The "automatically mandatory" keys (Section 7) are 1074 "port" and "no-default-alpn". (As described in Section 7, clients 1075 must either implement these keys or ignore any RR in which they 1076 appear.) Clients that restrict the HTTPS destination port (e.g. 1077 using the "bad ports" list from [FETCH]) SHOULD apply the same 1078 restriction to the "port" SvcParam. 1080 The presence of an HTTPS RR for an origin also indicates that all 1081 HTTP resources are available over HTTPS, as discussed in Section 8.5. 1082 This allows HTTPS RRs to apply to pre-existing "http" scheme URLs, 1083 while ensuring that the client uses a secure and authenticated HTTPS 1084 connection. 1086 The HTTPS RR parallels the concepts introduced in the HTTP 1087 Alternative Services proposed standard [AltSvc]. Clients and servers 1088 that implement HTTPS RRs are not required to implement Alt-Svc. 1090 8.1. Query names for HTTPS RRs 1092 The HTTPS RR uses Port Prefix Naming (Section 2.3), with one 1093 modification: if the scheme is "https" and the port is 443, then the 1094 client's original QNAME is equal to the service name (i.e. the 1095 origin's hostname), without any prefix labels. 1097 By removing the Attrleaf labels [Attrleaf] used in SVCB, this 1098 construction enables offline DNSSEC signing of wildcard domains, 1099 which are commonly used with HTTPS. Reusing the service name also 1100 allows the targets of existing CNAME chains (e.g. CDN hosts) to 1101 start returning HTTPS RR responses without requiring origin domains 1102 to configure and maintain an additional delegation. 1104 Following of HTTPS AliasMode RRs and CNAME aliases is unchanged from 1105 SVCB. 1107 Clients always convert "http" URLs to "https" before performing an 1108 HTTPS RR query using the process described in Section 8.5, so domain 1109 owners MUST NOT publish HTTPS RRs with a prefix of "_http". 1111 Note that none of these forms alter the HTTPS origin or authority. 1112 For example, clients MUST continue to validate TLS certificate 1113 hostnames based on the origin. 1115 8.2. Relationship to Alt-Svc 1117 Publishing a ServiceMode HTTPS RR in DNS is intended to be similar to 1118 transmitting an Alt-Svc field value over HTTPS, and receiving an 1119 HTTPS RR is intended to be similar to receiving that field value over 1120 HTTPS. However, there are some differences in the intended client 1121 and server behavior. 1123 8.2.1. ALPN usage 1125 Unlike Alt-Svc Field Values, HTTPS RRs can contain multiple ALPN IDs, 1126 and clients are encouraged to offer additional ALPNs that they 1127 support. 1129 8.2.2. Untrusted channel 1131 SVCB does not require or provide any assurance of authenticity. 1132 (DNSSEC signing and verification, which would provide such assurance, 1133 are OPTIONAL.) The DNS resolution process is treated as an untrusted 1134 channel that learns only the QNAME, and is prevented from mounting 1135 any attack beyond denial of service. 1137 Alt-Svc parameters that cannot be safely received in this model MUST 1138 NOT have a corresponding defined SvcParamKey. For example, there is 1139 no SvcParamKey corresponding to the Alt-Svc "persist" parameter, 1140 because this parameter is not safe to accept over an untrusted 1141 channel. 1143 8.2.3. Cache lifetime 1145 There is no SvcParamKey corresponding to the Alt-Svc "ma" (max age) 1146 parameter. Instead, server operators encode the expiration time in 1147 the DNS TTL. 1149 The appropriate TTL value might be different from the "ma" value used 1150 for Alt-Svc, depending on the desired efficiency and agility. Some 1151 DNS caches incorrectly extend the lifetime of DNS records beyond the 1152 stated TTL, so server operators cannot rely on HTTPS RRs expiring on 1153 time. Shortening the TTL to compensate for incorrect caching is NOT 1154 RECOMMENDED, as this practice impairs the performance of correctly 1155 functioning caches and does not guarantee faster expiration from 1156 incorrect caches. Instead, server operators SHOULD maintain 1157 compatibility with expired records until they observe that nearly all 1158 connections have migrated to the new configuration. 1160 8.2.4. Granularity 1162 Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc 1163 Field Value specifically to the client. When using an HTTPS RR, 1164 groups of clients will necessarily receive the same SvcParams. 1165 Therefore, HTTPS RRs are not suitable for uses that require single- 1166 client granularity. 1168 8.3. Interaction with Alt-Svc 1170 Clients that do not implement support for Encrypted ClientHello MAY 1171 skip the HTTPS RR query if a usable Alt-Svc value is available in the 1172 local cache. If Alt-Svc connection fails, these clients SHOULD fall 1173 back to the HTTPS RR client connection procedure (Section 3). 1175 Clients that implement support for ECH MUST perform the HTTPS RR 1176 query first, and MUST only make use of Alt-Svc when operating in 1177 SVCB-optional mode (see Section 9.1). 1179 This specification does not alter the DNS records used when 1180 connecting to an Alt-Svc hostname (typically A and/or AAAA only). 1182 8.4. Requiring Server Name Indication 1184 Clients MUST NOT use an HTTPS RR response unless the client supports 1185 TLS Server Name Indication (SNI) and indicate the origin name when 1186 negotiating TLS. This supports the conservation of IP addresses. 1188 Note that the TLS SNI (and also the HTTP "Host" or ":authority") will 1189 indicate the origin, not the TargetName. 1191 8.5. HTTP Strict Transport Security 1193 By publishing a usable HTTPS RR, the server operator indicates that 1194 all useful HTTP resources on that origin are reachable over HTTPS, 1195 similar to HTTP Strict Transport Security [HSTS]. 1197 Prior to making an "http" scheme request, the client SHOULD perform a 1198 lookup to determine if any HTTPS RRs exist for that origin. To do 1199 so, the client SHOULD construct a corresponding "https" URL as 1200 follows: 1202 1. Replace the "http" scheme with "https". 1204 2. If the "http" URL explicitly specifies port 80, specify port 443. 1206 3. Do not alter any other aspect of the URL. 1208 This construction is equivalent to Section 8.3 of [HSTS], point 5. 1210 If an HTTPS RR query for this "https" URL returns any AliasMode HTTPS 1211 RRs, or any compatible ServiceMode HTTPS RRs (see Section 7), the 1212 client SHOULD act as if it has received an HTTP "307 Temporary 1213 Redirect" redirect to this "https" URL. (Receipt of an incompatible 1214 ServiceMode RR does not trigger the redirect behavior.) Because 1215 HTTPS RRs are received over an often insecure channel (DNS), clients 1216 MUST NOT place any more trust in this signal than if they had 1217 received a 307 redirect over cleartext HTTP. 1219 When an HTTPS connection fails due to an error in the underlying 1220 secure transport, such as an error in certificate validation, some 1221 clients currently offer a "user recourse" that allows the user to 1222 bypass the security error and connect anyway. When making an "https" 1223 scheme request to an origin with an HTTPS RR, either directly or via 1224 the above redirect, such a client MAY remove the user recourse 1225 option. Origins that publish HTTPS RRs therefore MUST NOT rely on 1226 user recourse for access. For more information, see Section 8.4 and 1227 Section 12.1 of [HSTS]. 1229 8.6. HTTP-based protocols 1231 All protocols employing "http://" or "https://" URLs SHOULD respect 1232 HTTPS RRs. For example, clients that support HTTPS RRs and implement 1233 the altered WebSocket [WebSocket] opening handshake from the W3C 1234 Fetch specification [FETCH] SHOULD use HTTPS RRs for the 1235 "requestURL". 1237 An HTTP-based protocol MAY define its own SVCB mapping. Such 1238 mappings MAY be defined to take precedence over HTTPS RRs. 1240 9. SVCB/HTTPS RR parameter for ECH configuration 1242 The SVCB "echconfig" parameter is defined for conveying the ECH 1243 configuration of an alternative endpoint. In wire format, the value 1244 of the parameter is an ECHConfigList [ECH], including the redundant 1245 length prefix. In presentation format, the value is a single 1246 ECHConfigList encoded in Base64 [base64]. Base64 is used here to 1247 simplify integration with TLS server software. To enable simpler 1248 parsing, this SvcParam MUST NOT contain escape sequences. 1250 When ECH is in use, the TLS ClientHello is divided into an 1251 unencrypted "outer" and an encrypted "inner" ClientHello. The outer 1252 ClientHello is an implementation detail of ECH, and its contents are 1253 controlled by the ECHConfig in accordance with [ECH]. The inner 1254 ClientHello is used for establishing a connection to the service, so 1255 its contents may be influenced by other SVCB parameters. For 1256 example, the requirements on the ProtocolNameList in Section 6.1 1257 apply only to the inner ClientHello. Similarly, it is the inner 1258 ClientHello whose Server Name Indication identifies the desired 1259 service. 1261 9.1. Client behavior 1263 The SVCB-optional client behavior specified in Section 3 permits 1264 clients to fall back to a direct connection if all SVCB options fail. 1265 This behavior is not suitable for ECH, because fallback would negate 1266 the privacy benefits of ECH. Accordingly, ECH-capable SVCB-optional 1267 clients MUST switch to SVCB-reliant connection establishment if SVCB 1268 resolution succeeded (following Section 3) and all alternative 1269 endpoints have an "echconfig" key. 1271 As a latency optimization, clients MAY prefetch DNS records that will 1272 only be used in SVCB-optional mode. 1274 9.2. Deployment considerations 1276 An HTTPS RRSet containing some RRs with "echconfig" and some without 1277 is vulnerable to a downgrade attack. This configuration is NOT 1278 RECOMMENDED. Zone owners who do use such a mixed configuration 1279 SHOULD mark the RRs with "echconfig" as more preferred (i.e. smaller 1280 SvcPriority) than those without, in order to maximize the likelihood 1281 that ECH will be used in the absence of an active adversary. 1283 10. Zone Structures 1284 10.1. Structuring zones for flexibility 1286 Each ServiceForm RRSet can only serve a single scheme. The scheme is 1287 indicated by the owner name and the RR type. For the generic SVCB RR 1288 type, this means that each owner name can only be used for a single 1289 scheme. The underscore prefixing requirement (Section 2.3) ensures 1290 that this is true for the initial query, but it is the responsibility 1291 of zone owners to choose names that satisfy this constraint when 1292 using aliases, including CNAME and AliasMode records. 1294 When using the generic SVCB RR type with aliasing, zone owners SHOULD 1295 choose alias target names that indicate the scheme in use (e.g. 1296 "foosvc.example.net" for "foo://" schemes). This will help to avoid 1297 confusion when another scheme needs to be added to the configuration. 1299 10.2. Structuring zones for performance 1301 To avoid a delay for clients using a nonconforming recursive 1302 resolver, domain owners SHOULD minimize the use of AliasMode records, 1303 and SHOULD choose TargetName according to a predictable convention 1304 that is known to the client, so that clients can issue A and/or AAAA 1305 queries for TargetName in advance (see Section 5). Unless otherwise 1306 specified, the convention is to set TargetName to the service name 1307 for an initial ServiceMode record, or to "." if it is reached via an 1308 alias. For foo://foo.example.com:8080, this might look like: 1310 $ORIGIN example.com. ; Origin 1311 foo 3600 IN CNAME foosvc.example.net. 1312 _8080._foo.foo 3600 IN CNAME foosvc.example.net. 1314 $ORIGIN example.net. ; Service provider zone 1315 foosvc 3600 IN SVCB 1 . key65333=... 1316 foosvc 300 IN AAAA 2001:db8::1 1318 Domain owners SHOULD avoid using a TargetName that is below a DNAME, 1319 as this is likely unnecessary and makes responses slower and larger. 1320 Also, zone structures that require following more than 8 aliases 1321 (counting both AliasMode and CNAME records) are NOT RECOMMENDED. 1323 10.3. Examples 1325 10.3.1. Protocol enhancements 1327 Consider a simple zone of the form: 1329 $ORIGIN simple.example. ; Simple example zone 1330 @ 300 IN A 192.0.2.1 1331 AAAA 2001:db8::1 1333 The domain owner could add this record: 1335 simple.example. 7200 IN HTTPS 1 . alpn=h3 1337 to indicate that simple.example uses HTTPS, and supports QUIC in 1338 addition to HTTPS over TCP (an implicit default). The record could 1339 also include other information (e.g. non-standard port, ECH 1340 configuration). 1342 10.3.2. Apex aliasing 1344 Consider a zone that is using CNAME aliasing: 1346 $ORIGIN aliased.example. ; A zone that is using a hosting service 1347 ; Subdomain aliased to a high-performance server pool 1348 www 7200 IN CNAME pool.svc.example. 1349 ; Apex domain on fixed IPs because CNAME is not allowed at the apex 1350 @ 300 IN A 192.0.2.1 1351 IN AAAA 2001:db8::1 1353 With HTTPS RRs, the owner of aliased.example could alias the apex by 1354 adding one additional record: 1356 @ 7200 IN HTTPS 0 pool.svc.example. 1358 With this record in place, HTTPS-RR-aware clients will use the same 1359 server pool for aliased.example and www.aliased.example. (They will 1360 also upgrade to HTTPS on aliased.example.) Non-HTTPS-RR-aware 1361 clients will just ignore the new record. 1363 Similar to CNAME, HTTPS RRs have no impact on the origin name. When 1364 connecting, clients will continue to treat the authoritative origins 1365 as "https://www.aliased.example" and "https://aliased.example", 1366 respectively, and will validate TLS server certificates accordingly. 1368 10.3.3. Parameter binding 1370 Suppose that svc.example's default server pool supports HTTP/2, and 1371 it has deployed HTTP/3 on a new server pool with a different 1372 configuration. This can be expressed in the following form: 1374 $ORIGIN svc.example. ; A hosting provider. 1375 pool 7200 IN HTTPS 1 h3pool alpn=h2,h3 echconfig="123..." 1376 HTTPS 2 . alpn=h2 echconfig="abc..." 1377 pool 300 IN A 192.0.2.2 1378 AAAA 2001:db8::2 1379 h3pool 300 IN A 192.0.2.3 1380 AAAA 2001:db8::3 1382 This configuration is entirely compatible with the "Apex aliasing" 1383 example, whether the client supports HTTPS RRs or not. If the client 1384 does support HTTPS RRs, all connections will be upgraded to HTTPS, 1385 and clients will use HTTP/3 if they can. Parameters are "bound" to 1386 each server pool, so each server pool can have its own protocol, ECH 1387 configuration, etc. 1389 10.3.4. Multi-CDN 1391 The HTTPS RR is intended to support HTTPS services operated by 1392 multiple independent entities, such as different Content Delivery 1393 Networks (CDNs) or different hosting providers. This includes the 1394 case where a service is migrated from one operator to another, as 1395 well as the case where the service is multiplexed between multiple 1396 operators for performance, redundancy, etc. 1398 This example shows such a configuration, with www.customer.example 1399 having different DNS responses to different queries, either over time 1400 or due to logic within the authoritative DNS server: 1402 ; This zone contains/returns different CNAME records 1403 ; at different points-in-time. The RRset for "www" can 1404 ; only ever contain a single CNAME. 1406 ; Sometimes the zone has: 1407 $ORIGIN customer.example. ; A Multi-CDN customer domain 1408 www 900 IN CNAME cdn1.svc1.example. 1410 ; and other times it contains: 1411 $ORIGIN customer.example. 1412 www 900 IN CNAME customer.svc2.example. 1414 ; and yet other times it contains: 1415 $ORIGIN customer.example. 1416 www 900 IN CNAME cdn3.svc3.example. 1418 ; With the following remaining constant and always included: 1419 $ORIGIN customer.example. ; A Multi-CDN customer domain 1420 ; The apex is also aliased to www to match its configuration 1421 @ 7200 IN HTTPS 0 www 1422 ; Non-HTTPS-aware clients use non-CDN IPs 1423 A 203.0.113.82 1424 AAAA 2001:db8:203::2 1426 ; Resolutions following the cdn1.svc1.example 1427 ; path use these records. 1428 ; This CDN uses a different alternative service for HTTP/3. 1429 $ORIGIN svc1.example. ; domain for CDN 1 1430 cdn1 1800 IN HTTPS 1 h3pool alpn=h3 echconfig="123..." 1431 HTTPS 2 . alpn=h2 echconfig="123..." 1432 A 192.0.2.2 1433 AAAA 2001:db8:192::4 1434 h3pool 300 IN A 192.0.2.3 1435 AAAA 2001:db8:192:7::3 1437 ; Resolutions following the customer.svc2.example 1438 ; path use these records. 1439 ; Note that this CDN only supports HTTP/2. 1440 $ORIGIN svc2.example. ; domain operated by CDN 2 1441 customer 300 IN HTTPS 1 . alpn=h2 echconfig="xyz..." 1442 60 IN A 198.51.100.2 1443 A 198.51.100.3 1444 A 198.51.100.4 1445 AAAA 2001:db8:198::7 1446 AAAA 2001:db8:198::12 1448 ; Resolutions following the customer.svc2.example 1449 ; path use these records. 1450 ; Note that this CDN has no HTTPS records 1451 ; and thus no ECH support. 1452 $ORIGIN svc3.example. ; domain operated by CDN 3 1453 cdn3 60 IN A 203.0.113.8 1454 AAAA 2001:db8:113::8 1456 Note that in the above example, the different CDNs have different 1457 echconfig and different capabilities, but clients will use HTTPS RRs 1458 as a bound-together unit. 1460 Domain owners should be cautious when using a multi-CDN 1461 configuration, as it introduces a number of complexities highlighted 1462 by this example: 1464 o If CDN 1 supports ECH, and CDN 2 does not, the client is 1465 vulnerable to ECH downgrade by a network adversary who forces 1466 clients to get CDN 2 records. 1468 o Aliasing the apex to its subdomain simplifies the zone file but 1469 likely increases resolution latency, especially when using a non- 1470 HTTPS-aware recursive resolver. An alternative would be to alias 1471 the zone apex directly to a name managed by a CDN. 1473 o The A, AAAA, HTTPS resolutions are independent lookups so clients 1474 may observe and follow different CNAMEs to different CDNs. 1475 Clients may thus find a SvcDomainName pointing to a name other 1476 than the one which returned along with the A and AAAA lookups and 1477 will need to do an additional resolution for them. Including 1478 ipv6hint and ipv4hint will reduce the performance impact of this 1479 case. 1481 o If not all CDNs publish HTTPS records, clients will sometimes 1482 receive NODATA for HTTPS queries (as with cdn3.svc3.example 1483 above), and thus no echconfig, but could receive A/AAAA records 1484 from a different CDN which does support ECH. Clients will be 1485 unable to use ECH in this case. 1487 10.3.5. Non-HTTPS uses 1489 For services other than HTTPS, the SVCB RR and an Attrleaf label 1490 [Attrleaf] will be used. For example, to reach an example resource 1491 of "baz://api.example.com:8765", the following SVCB record would be 1492 used to alias it to "svc4-baz.example.net." which in-turn could 1493 return AAAA/A records and/or SVCB records in ServiceMode: 1495 _8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net. 1497 HTTPS RRs use similar Attrleaf labels if the origin contains a non- 1498 default port. 1500 11. Interaction with other standards 1502 This standard is intended to reduce connection latency and improve 1503 user privacy. Server operators implementing this standard SHOULD 1504 also implement TLS 1.3 [RFC8446] and OCSP Stapling [RFC6066], both of 1505 which confer substantial performance and privacy benefits when used 1506 in combination with SVCB records. 1508 To realize the greatest privacy benefits, this proposal is intended 1509 for use over a privacy-preserving DNS transport (like DNS over TLS 1510 [DoT] or DNS over HTTPS [DoH]). However, performance improvements, 1511 and some modest privacy improvements, are possible without the use of 1512 those standards. 1514 Any specification for use of SVCB with a protocol MUST have an entry 1515 for its scheme under the SVCB RR type in the IANA DNS Underscore 1516 Global Scoped Entry Registry [Attrleaf]. The scheme SHOULD have an 1517 entry in the IANA URI Schemes Registry [RFC7595]. The scheme SHOULD 1518 have a defined specification for use with SVCB. 1520 12. Security Considerations 1522 SVCB/HTTPS RRs are intended for distribution over untrusted channels, 1523 and clients are REQUIRED to verify that the alternative endpoint is 1524 authoritative for the service (similar to Section 2.1 of [AltSvc]). 1526 Therefore, DNSSEC signing and validation are OPTIONAL for publishing 1527 and using SVCB and HTTPS RRs. 1529 Clients MUST ensure that their DNS cache is partitioned for each 1530 local network, or flushed on network changes, to prevent a local 1531 adversary in one network from implanting a forged DNS record that 1532 allows them to track users or hinder their connections after they 1533 leave that network. 1535 An attacker who can prevent SVCB resolution can deny clients any 1536 associated security benefits. A hostile recursive resolver can 1537 always deny service to SVCB queries, but network intermediaries can 1538 often prevent resolution as well, even when the client and recursive 1539 resolver validate DNSSEC and use a secure transport. These downgrade 1540 attacks can prevent the HTTPS upgrade provided by the HTTPS RR 1541 (Section 8.5), and disable the encryption enabled by the echconfig 1542 SvcParamKey (Section 9). To prevent downgrades, Section 3.1 1543 recommends that clients abandon the connection attempt when such an 1544 attack is detected. 1546 A hostile DNS intermediary might forge AliasForm "." records 1547 (Section 2.5.1) as a way to block clients from accessing particular 1548 services. Such an adversary could already block entire domains by 1549 forging erroneous responses, but this mechanism allows them to target 1550 particular protocols or ports within a domain. Clients that might be 1551 subject to such attacks SHOULD ignore AliasForm "." records. 1553 A hostile DNS intermediary or origin can return SVCB records 1554 indicating any IP address and port number, including IP addresses 1555 inside the local network and port numbers assigned to internal 1556 services. If the attacker can influence the client's payload (e.g. 1557 TLS session ticket contents), and an internal service has a 1558 sufficiently lax parser, it's possible that the attacker could gain 1559 unintended access. (The same concerns apply to SRV records, HTTP 1560 Alt-Svc, and HTTP redirects.) As a mitigation, SVCB mapping 1561 documents SHOULD indicate any port number restrictions that are 1562 appropriate for the supported transports. 1564 13. Privacy Considerations 1566 Standard address queries reveal the user's intent to access a 1567 particular domain. This information is visible to the recursive 1568 resolver, and to many other parties when plaintext DNS transport is 1569 used. SVCB queries, like queries for SRV records and other specific 1570 RR types, additionally reveal the user's intent to use a particular 1571 protocol. This is not normally sensitive information, but it should 1572 be considered when adding SVCB support in a new context. 1574 14. IANA Considerations 1576 14.1. SVCB RRType 1578 This document defines a new DNS RR type, SVCB, whose value 64 has 1579 been allocated by IANA from the "Resource Record (RR) TYPEs" 1580 subregistry of the "Domain Name System (DNS) Parameters" registry: 1582 Type: SVCB 1584 Value: 64 1586 Meaning: General Purpose Service Endpoints 1588 Reference: This document 1590 14.2. HTTPS RRType 1592 This document defines a new DNS RR type, HTTPS, whose value 65 has 1593 been allocated by IANA from the "Resource Record (RR) TYPEs" 1594 subregistry of the "Domain Name System (DNS) Parameters" registry: 1596 Type: HTTPS 1598 Value: 65 1600 Meaning: HTTPS Specific Service Endpoints 1602 Reference: This document 1604 14.3. New registry for Service Parameters 1606 The "Service Binding (SVCB) Parameter Registry" defines the namespace 1607 for parameters, including string representations and numeric 1608 SvcParamKey values. This registry is shared with other SVCB- 1609 compatible RR types, such as the HTTPS RR. 1611 ACTION: create and include a reference to this registry. 1613 14.3.1. Procedure 1615 A registration MUST include the following fields: 1617 o Number: wire format numeric identifier (range 0-65535) 1619 o Name: unique presentation name 1621 o Meaning: a short description 1622 o Format Reference: pointer to specification text 1624 The characters in the registered Name MUST be lower-case alphanumeric 1625 or "-" (Section 2.1). The name MUST NOT start with "key" or 1626 "invalid". 1628 Entries in this registry are subject to a First Come First Served 1629 registration policy ([RFC8126], Section 4.6). The Format Reference 1630 MUST specify how to convert the SvcParamValue's presentation format 1631 to wire format and MAY detail its intended meaning and use. An entry 1632 MAY specify a Format Reference of the form "Same as (other key Name)" 1633 if it uses the same presentation and wire formats as an existing key. 1635 This arrangement supports the development of new parameters while 1636 ensuring that zone files can be made interoperable. 1638 14.3.2. Initial contents 1640 The "Service Binding (SVCB) Parameter Registry" shall initially be 1641 populated with the registrations below: 1643 +-------------+-----------------+------------------+----------------+ 1644 | Number | Name | Meaning | Format | 1645 | | | | Reference | 1646 +-------------+-----------------+------------------+----------------+ 1647 | 0 | mandatory | Mandatory keys | (This | 1648 | | | in this RR | document) | 1649 | | | | Section 7 | 1650 | | | | | 1651 | 1 | alpn | Additional | (This | 1652 | | | supported | document) | 1653 | | | protocols | Section 6.1 | 1654 | | | | | 1655 | 2 | no-default-alpn | No support for | (This | 1656 | | | default protocol | document) | 1657 | | | | Section 6.1 | 1658 | | | | | 1659 | 3 | port | Port for | (This | 1660 | | | alternative | document) | 1661 | | | endpoint | Section 6.2 | 1662 | | | | | 1663 | 4 | ipv4hint | IPv4 address | (This | 1664 | | | hints | document) | 1665 | | | | Section 6.4 | 1666 | | | | | 1667 | 5 | echconfig | Encrypted | (This | 1668 | | | ClientHello info | document) | 1669 | | | | Section 6.3 | 1670 | | | | | 1671 | 6 | ipv6hint | IPv6 address | (This | 1672 | | | hints | document) | 1673 | | | | Section 6.4 | 1674 | | | | | 1675 | 65280-65534 | N/A | Private Use | (This | 1676 | | | | document) | 1677 | | | | | 1678 | 65535 | N/A | Reserved | (This | 1679 | | | ("Invalid key") | document) | 1680 +-------------+-----------------+------------------+----------------+ 1682 14.4. Registry updates 1684 Per [RFC6895], please add the following entries to the data type 1685 range of the Resource Record (RR) TYPEs registry: 1687 +-------+------------------------------------------+----------------+ 1688 | TYPE | Meaning | Reference | 1689 +-------+------------------------------------------+----------------+ 1690 | SVCB | Service Location and Parameter Binding | (This | 1691 | | | document) | 1692 | | | | 1693 | HTTPS | HTTPS Service Location and Parameter | (This | 1694 | | Binding | document) | 1695 +-------+------------------------------------------+----------------+ 1697 Per [Attrleaf], please add the following entry to the DNS Underscore 1698 Global Scoped Entry Registry: 1700 +---------+------------+-----------------+-----------------+ 1701 | RR TYPE | _NODE NAME | Meaning | Reference | 1702 +---------+------------+-----------------+-----------------+ 1703 | HTTPS | _https | HTTPS SVCB info | (This document) | 1704 +---------+------------+-----------------+-----------------+ 1706 15. Acknowledgments and Related Proposals 1708 There have been a wide range of proposed solutions over the years to 1709 the "CNAME at the Zone Apex" challenge proposed. These include 1710 [I-D.bellis-dnsop-http-record], [I-D.ietf-dnsop-aname], and others. 1712 Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thomson, Lucas 1713 Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, David 1714 Benjamin, Mark Andrews, Emily Stark, Eric Orth, Kyle Rose, Craig 1715 Taylor, Dan McArdle, Brian Dickson, and others for their feedback and 1716 suggestions on this draft. 1718 16. References 1720 16.1. Normative References 1722 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1723 "Transport Layer Security (TLS) Application-Layer Protocol 1724 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1725 July 2014, . 1727 [Attrleaf] 1728 Crocker, D., "Scoped Interpretation of DNS Resource 1729 Records through "Underscored" Naming of Attribute Leaves", 1730 BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, 1731 . 1733 [base64] Josefsson, S., "The Base16, Base32, and Base64 Data 1734 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1735 . 1737 [DNAME] Rose, S. and W. Wijngaards, "DNAME Redirection in the 1738 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 1739 . 1741 [DoH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1742 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1743 . 1745 [DoT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1746 and P. Hoffman, "Specification for DNS over Transport 1747 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1748 2016, . 1750 [ECH] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 1751 Encrypted Client Hello", draft-ietf-tls-esni-09 (work in 1752 progress), December 2020. 1754 [HappyEyeballsV2] 1755 Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1756 Better Connectivity Using Concurrency", RFC 8305, 1757 DOI 10.17487/RFC8305, December 2017, 1758 . 1760 [HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1761 Transport Security (HSTS)", RFC 6797, 1762 DOI 10.17487/RFC6797, November 2012, 1763 . 1765 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 1766 (HTTP/3)", draft-ietf-quic-http-33 (work in progress), 1767 December 2020. 1769 [RFC1035] Mockapetris, P., "Domain names - implementation and 1770 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1771 November 1987, . 1773 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1774 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1775 DOI 10.17487/RFC1928, March 1996, 1776 . 1778 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1779 Requirement Levels", BCP 14, RFC 2119, 1780 DOI 10.17487/RFC2119, March 1997, 1781 . 1783 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 1784 RFC 3225, DOI 10.17487/RFC3225, December 2001, 1785 . 1787 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 1788 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 1789 2003, . 1791 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1792 Specifications: ABNF", STD 68, RFC 5234, 1793 DOI 10.17487/RFC5234, January 2008, 1794 . 1796 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1797 Address Text Representation", RFC 5952, 1798 DOI 10.17487/RFC5952, August 2010, 1799 . 1801 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1802 Extensions: Extension Definitions", RFC 6066, 1803 DOI 10.17487/RFC6066, January 2011, 1804 . 1806 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1807 Beijnum, "DNS64: DNS Extensions for Network Address 1808 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1809 DOI 10.17487/RFC6147, April 2011, 1810 . 1812 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1813 the IPv6 Prefix Used for IPv6 Address Synthesis", 1814 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1815 . 1817 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1818 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1819 DOI 10.17487/RFC7231, June 2014, 1820 . 1822 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 1823 and Registration Procedures for URI Schemes", BCP 35, 1824 RFC 7595, DOI 10.17487/RFC7595, June 2015, 1825 . 1827 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1828 Writing an IANA Considerations Section in RFCs", BCP 26, 1829 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1830 . 1832 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1833 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1834 May 2017, . 1836 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1837 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1838 . 1840 [WebSocket] 1841 Fette, I. and A. Melnikov, "The WebSocket Protocol", 1842 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1843 . 1845 16.2. Informative References 1847 [AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1848 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1849 April 2016, . 1851 [DNSTerm] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1852 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1853 January 2019, . 1855 [FETCH] "Fetch Living Standard", May 2020, 1856 . 1858 [I-D.bellis-dnsop-http-record] 1859 Bellis, R., "A DNS Resource Record for HTTP", draft- 1860 bellis-dnsop-http-record-00 (work in progress), November 1861 2018. 1863 [I-D.ietf-dnsop-aname] 1864 Finch, T., Hunt, E., Dijk, P., Eden, A., and W. Mekking, 1865 "Address-specific DNS aliases (ANAME)", draft-ietf-dnsop- 1866 aname-04 (work in progress), July 2019. 1868 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1869 DOI 10.17487/RFC6454, December 2011, 1870 . 1872 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 1873 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 1874 April 2013, . 1876 [SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1877 specifying the location of services (DNS SRV)", RFC 2782, 1878 DOI 10.17487/RFC2782, February 2000, 1879 . 1881 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1882 Resource Identifier (URI): Generic Syntax", STD 66, 1883 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1884 . 1886 16.3. URIs 1888 [1] https://github.com/MikeBishop/dns-alt-svc 1890 Appendix A. Decoding text in zone files 1892 DNS zone files are capable of representing arbitrary octet sequences 1893 in basic ASCII text, using various delimiters and encodings. The 1894 algorithm for decoding these character-strings is defined in 1895 Section 5.1 of [RFC1035]. Here we summarize the allowed input to 1896 that algorithm, using ABNF: 1898 ; non-special is VCHAR minus DQUOTE, ";", "(", ")", and "\". 1899 non-special = %x21 / %x23-27 / %x2A-3A / %x3C-5B / %x5D-7E 1900 ; non-digit is VCHAR minus DIGIT 1901 non-digit = %x21-2F / %x3A-7E 1902 ; dec-octet is a number 0-255 as a three-digit decimal number. 1903 dec-octet = ( "0" / "1" ) 2DIGIT / 1904 "2" ( ( %x30-34 DIGIT ) / ( "5" %x30-35 ) ) 1905 escaped = "\" ( non-digit / dec-octet ) 1906 contiguous = 1*( non-special / escaped ) 1907 quoted = DQUOTE *( contiguous / ( ["\"] WSP ) ) DQUOTE 1908 char-string = contiguous / quoted 1910 The decoding algorithm allows "char-string" to represent any 1911 "*OCTET". In this document, this algorithm is referred to as 1912 "character-string decoding". The algorithm is the same as used by 1913 "" in RFC 1035, although the output length in this 1914 document is not limited to 255 octets. 1916 A.1. Decoding a comma-separated list 1918 In order to represent lists of items in zone files, this 1919 specification uses comma-separated lists. When "," is not escaped 1920 (by a preceding "\"), it separates items in the list. (For 1921 simplicity, empty items are not allowed.) 1922 item = 1*OCTET 1923 ; item-allowed is OCTET minus "," and "\". 1924 item-allowed = %x00-2B / %x2D-5B / %x5D-FF 1925 escaped-item = 1*(item-allowed / "\," / "\\") 1926 comma-separated = [escaped-item *("," escaped-item)] 1928 Decoding of value-lists happens after character-string decoding. 1929 For example, consider these "char-string" SvcParamValues: 1931 "part1,part2,part3\\,part4\\\\" 1932 part1\,\p\a\r\t2\044part3\092,part4\092\\ 1934 These inputs are equivalent: character-string decoding either of them 1935 would produce the same "value": 1937 part1,part2,part3\,part4\\ 1939 Applying comma-separated list decoding to this "value" would produce 1940 a list of three "item"s: 1942 part1 1943 part2 1944 part3,part4\ 1946 Appendix B. HTTP Mapping Summary 1948 This table serves as a non-normative summary of the HTTP mapping for 1949 SVCB (Section 8). Future protocol mappings may provide a similar 1950 summary table. 1952 +-----------------------------+-------------------------------------+ 1953 | *Mapped scheme* | "https" | 1954 | | | 1955 | *Other affected schemes* | "http", "wss", "ws", (other HTTP- | 1956 | | based) | 1957 | | | 1958 | *RR type* | HTTPS (65) | 1959 | | | 1960 | *Name prefix* | None for port 443, else | 1961 | | "_$PORT._https" | 1962 | | | 1963 | *Automatically Mandatory | "port", "no-default-alpn" | 1964 | Keys* | | 1965 | | | 1966 | *SvcParam defaults* | "alpn": ["http/1.1"] | 1967 | | | 1968 | *Special behaviors* | HTTP to HTTPS upgrade | 1969 +-----------------------------+-------------------------------------+ 1970 This table does not indicate any SvcParamKeys that servers are 1971 required to publish, or that clients are required to implement, 1972 because there are none in this mapping. 1974 Appendix C. Comparison with alternatives 1976 The SVCB and HTTPS RR types closely resemble, and are inspired by, 1977 some existing record types and proposals. A complaint with all of 1978 the alternatives is that web clients have seemed unenthusiastic about 1979 implementing them. The hope here is that by providing an extensible 1980 solution that solves multiple problems we will overcome the inertia 1981 and have a path to achieve client implementation. 1983 C.1. Differences from the SRV RR type 1985 An SRV record [SRV] can perform a similar function to the SVCB 1986 record, informing a client to look in a different location for a 1987 service. However, there are several differences: 1989 o SRV records are typically mandatory, whereas clients will always 1990 continue to function correctly without making use of SVCB. 1992 o SRV records cannot instruct the client to switch or upgrade 1993 protocols, whereas SVCB can signal such an upgrade (e.g. to 1994 HTTP/2). 1996 o SRV records are not extensible, whereas SVCB and HTTPS RRs can be 1997 extended with new parameters. 1999 o SVCB records use 16 bit for SvcPriority for consistency with SRV 2000 and other RR types that also use 16 bit priorities. 2002 C.2. Differences from the proposed HTTP record 2004 Unlike [I-D.bellis-dnsop-http-record], this approach is extensible to 2005 cover Alt-Svc and Encrypted ClientHello use-cases. Like that 2006 proposal, this addresses the zone apex CNAME challenge. 2008 Like that proposal, it remains necessary to continue to include 2009 address records at the zone apex for legacy clients. 2011 C.3. Differences from the proposed ANAME record 2013 Unlike [I-D.ietf-dnsop-aname], this approach is extensible to cover 2014 Alt-Svc and ECH use-cases. This approach also does not require any 2015 changes or special handling on either authoritative or primary 2016 servers, beyond optionally returning in-bailiwick additional records. 2018 Like that proposal, this addresses the zone apex CNAME challenge for 2019 clients that implement this. 2021 However, with this SVCB proposal, it remains necessary to continue to 2022 include address records at the zone apex for legacy clients. If 2023 deployment of this standard is successful, the number of legacy 2024 clients will fall over time. As the number of legacy clients 2025 declines, the operational effort required to serve these users 2026 without the benefit of SVCB indirection should fall. Server 2027 operators can easily observe how much traffic reaches this legacy 2028 endpoint, and may remove the apex's address records if the observed 2029 legacy traffic has fallen to negligible levels. 2031 C.4. Comparison with separate RR types for AliasMode and ServiceMode 2033 Abstractly, functions of AliasMode and ServiceMode are independent, 2034 so it might be tempting to specify them as separate RR types. 2035 However, this would result in a serious performance impairment, 2036 because clients cannot rely on their recursive resolver to follow 2037 SVCB aliases (unlike CNAME). Thus, clients would have to issue 2038 queries for both RR types in parallel, potentially at each step of 2039 the alias chain. Recursive resolvers that implement the 2040 specification would, upon receipt of a ServiceMode query, emit both a 2041 ServiceMode and an AliasMode query to the authoritative. Thus, 2042 splitting the RR type would double, or in some cases triple, the load 2043 on clients and servers, and would not reduce implementation 2044 complexity. 2046 Appendix D. Change history 2048 o draft-ietf-dnsop-svcb-https-04 2050 * Simplify the IANA instructions (pure First Come First Served) 2052 * Recommend against publishing chains of >8 aliases 2054 * Clarify requirements for using SVCB with a transport proxy 2056 * Adjust guidance for Port Prefix Naming 2058 * Minor editorial updates 2060 o draft-ietf-dnsop-svcb-https-03 2062 * Simplified escaping of comma-separated values 2064 * Reorganized client requirements 2065 * Added a warning about port filtering for cross-protocol attacks 2067 * Clarified self-consistency rules for SvcParams 2069 * Added a non-normative mapping summary table for HTTPS 2071 o draft-ietf-dnsop-svcb-https-02 2073 * Added a Privacy Considerations section 2075 * Adjusted resolution fallback description 2077 * Clarified status of SvcParams in AliasMode 2079 * Improved advice on zone structuring and use with Alt-Svc 2081 * Improved examples, including a new Multi-CDN example 2083 * Reorganized text on value-list parsing and SvcPriority 2085 * Improved phrasing and other editorial improvements throughout 2087 o draft-ietf-dnsop-svcb-https-01 2089 * Added a "mandatory" SvcParamKey 2091 * Added the ability to indicate that a service does not exist 2093 * Adjusted resolution and ALPN algorithms 2095 * Major terminology revisions for "origin" and CamelCase names 2097 * Revised ABNF 2099 * Include allocated RR type numbers 2101 * Various corrections, explanations, and recommendations 2103 o draft-ietf-dnsop-svcb-https-00 2105 * Rename HTTPSSVC RR to HTTPS RR 2107 * Rename "an SVCB" to "a SVCB" 2109 * Removed "design considerations and open issues" section and 2110 some other "to be removed" text 2112 o draft-ietf-dnsop-svcb-httpssvc-03 2113 * Revised chain length limit requirements 2115 * Revised IANA registry rules for SvcParamKeys 2117 * Require HTTPS clients to implement SNI 2119 * Update terminology for Encrypted ClientHello 2121 * Clarifications: non-default ports, transport proxies, HSTS 2122 procedure, WebSocket behavior, wire format, IP hints, inner/ 2123 outer ClientHello with ECH 2125 * Various textual and ABNF corrections 2127 o draft-ietf-dnsop-svcb-httpssvc-02 2129 * All changes to Alt-Svc have been removed 2131 * Expanded and reorganized examples 2133 * Priority zero is now the definition of AliasForm 2135 * Repeated SvcParamKeys are no longer allowed 2137 * The "=" sign may be omitted in a key=value pair if the value is 2138 also empty 2140 * In the wire format, SvcParamKeys must be in sorted order 2142 * New text regarding how to handle resolution timeouts 2144 * Expanded description of recursive resolver behavior 2146 * Much more precise description of the intended ALPN behavior 2148 * Match the HSTS specification's language on HTTPS enforcement 2150 * Removed 'esniconfig=""' mechanism and simplified ESNI 2151 connection logic 2153 o draft-ietf-dnsop-svcb-httpssvc-01 2155 * Reduce the emphasis on conversion between HTTPSSVC and Alt-Svc 2157 * Make the "untrusted channel" concept more precise. 2159 * Make SvcFieldPriority = 0 the definition of AliasForm, instead 2160 of a requirement. 2162 o draft-ietf-dnsop-svcb-httpssvc-00 2164 * Document an optimization for optimistic pre-connection. (Chris 2165 Wood) 2167 * Relax IP hint handling requirements. (Eric Rescorla) 2169 o draft-nygren-dnsop-svcb-httpssvc-00 2171 * Generalize to an SVCB record, with special-case handling for 2172 Alt-Svc and HTTPS separated out to dedicated sections. 2174 * Split out a separate HTTPSSVC record for the HTTPS use-case. 2176 * Remove the explicit SvcRecordType=0/1 and instead make the 2177 AliasForm vs ServiceForm be implicit. This was based on 2178 feedback recommending against subtyping RR type. 2180 * Remove one optimization. 2182 o draft-nygren-httpbis-httpssvc-03 2184 * Change redirect type for HSTS-style behavior from 302 to 307 to 2185 reduce ambiguities. 2187 o draft-nygren-httpbis-httpssvc-02 2189 * Remove the redundant length fields from the wire format. 2191 * Define a SvcDomainName of "." for SvcRecordType=1 as being the 2192 HTTPSSVC RRNAME. 2194 * Replace "hq" with "h3". 2196 o draft-nygren-httpbis-httpssvc-01 2198 * Fixes of record name. Replace references to "HTTPSVC" with 2199 "HTTPSSVC". 2201 o draft-nygren-httpbis-httpssvc-00 2203 * Initial version 2205 Authors' Addresses 2206 Ben Schwartz 2207 Google 2209 Email: bemasc@google.com 2211 Mike Bishop 2212 Akamai Technologies 2214 Email: mbishop@evequefou.be 2216 Erik Nygren 2217 Akamai Technologies 2219 Email: erik+ietf@nygren.org