idnits 2.17.1 draft-ietf-dnsop-svcb-https-01.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1383 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 1724 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-07 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-29 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 8499 (ref. 'DNSTerm') (Obsoleted by RFC 9499) == Outdated reference: A later version (-01) exists of draft-tapril-ns2-00 Summary: 3 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: January 14, 2021 E. Nygren 6 Akamai Technologies 7 July 13, 2020 9 Service binding and parameter specification via the DNS (DNS SVCB and 10 HTTPS RRs) 11 draft-ietf-dnsop-svcb-https-01 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 proposal is inspired by and based on recent DNS 28 usage proposals such as ALTSVC, ANAME, and ESNIKEYS (as well as long 29 standing desires to have SRV or a functional equivalent implemented 30 for HTTP). These proposals each provide an important function but 31 are potentially incompatible with each other, such as when an origin 32 is load-balanced across multiple hosting providers (multi-CDN). 33 Furthermore, these each add potential cases for adding additional 34 record lookups in addition to AAAA/A lookups. This design attempts 35 to provide a unified framework that encompasses the key functionality 36 of these proposals, as well as providing some extensibility for 37 addressing similar future challenges. 39 TO BE REMOVED: This document is being collaborated on in Github at: 40 https://github.com/MikeBishop/dns-alt-svc [1]. The most recent 41 working version of the document, open issues, etc. should all be 42 available there. The authors (gratefully) accept pull requests. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on January 14, 2021. 61 Copyright Notice 63 Copyright (c) 2020 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (https://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.1. Goals of the SVCB RR . . . . . . . . . . . . . . . . . . 5 80 1.2. Overview of the SVCB RR . . . . . . . . . . . . . . . . . 6 81 1.3. Parameter for Encrypted ClientHello . . . . . . . . . . . 7 82 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 83 2. The SVCB record type . . . . . . . . . . . . . . . . . . . . 7 84 2.1. Zone file presentation format . . . . . . . . . . . . . . 8 85 2.2. RDATA wire format . . . . . . . . . . . . . . . . . . . . 9 86 2.3. SVCB owner names . . . . . . . . . . . . . . . . . . . . 10 87 2.4. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 2.4.1. AliasMode . . . . . . . . . . . . . . . . . . . . . . 11 89 2.4.2. ServiceMode . . . . . . . . . . . . . . . . . . . . . 12 90 2.4.3. SvcPriority . . . . . . . . . . . . . . . . . . . . . 12 91 2.5. Special handling of "." in TargetName . . . . . . . . . . 12 92 2.5.1. AliasMode . . . . . . . . . . . . . . . . . . . . . . 13 93 2.5.2. ServiceMode . . . . . . . . . . . . . . . . . . . . . 13 94 3. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 13 95 3.1. Handling resolution failures . . . . . . . . . . . . . . 14 96 3.2. Clients using a Proxy . . . . . . . . . . . . . . . . . . 14 98 4. DNS Server Behavior . . . . . . . . . . . . . . . . . . . . . 15 99 4.1. Authoritative servers . . . . . . . . . . . . . . . . . . 15 100 4.2. Recursive resolvers . . . . . . . . . . . . . . . . . . . 15 101 4.3. General requirements . . . . . . . . . . . . . . . . . . 16 102 5. Performance optimizations . . . . . . . . . . . . . . . . . . 16 103 5.1. Optimistic pre-connection and connection reuse . . . . . 17 104 5.2. Generating and using incomplete responses . . . . . . . . 17 105 5.3. Structuring zones for performance . . . . . . . . . . . . 18 106 6. Initial SvcParamKeys . . . . . . . . . . . . . . . . . . . . 18 107 6.1. "alpn" and "no-default-alpn" . . . . . . . . . . . . . . 18 108 6.2. "port" . . . . . . . . . . . . . . . . . . . . . . . . . 20 109 6.3. "echconfig" . . . . . . . . . . . . . . . . . . . . . . . 20 110 6.4. "ipv4hint" and "ipv6hint" . . . . . . . . . . . . . . . . 21 111 6.5. "mandatory" . . . . . . . . . . . . . . . . . . . . . . . 22 112 7. Using SVCB with HTTPS and HTTP . . . . . . . . . . . . . . . 22 113 7.1. Owner names for HTTPS RRs . . . . . . . . . . . . . . . . 23 114 7.2. Relationship to Alt-Svc . . . . . . . . . . . . . . . . . 24 115 7.2.1. ALPN usage . . . . . . . . . . . . . . . . . . . . . 24 116 7.2.2. Untrusted channel . . . . . . . . . . . . . . . . . . 24 117 7.2.3. TTL and granularity . . . . . . . . . . . . . . . . . 24 118 7.3. Interaction with Alt-Svc . . . . . . . . . . . . . . . . 25 119 7.4. Requiring Server Name Indication . . . . . . . . . . . . 25 120 7.5. HTTP Strict Transport Security . . . . . . . . . . . . . 25 121 7.6. HTTP-based protocols . . . . . . . . . . . . . . . . . . 26 122 8. SVCB/HTTPS RR parameter for ECH configuration . . . . . . . . 26 123 8.1. Client behavior . . . . . . . . . . . . . . . . . . . . . 27 124 8.2. Deployment considerations . . . . . . . . . . . . . . . . 27 125 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 27 126 9.1. Protocol enhancements . . . . . . . . . . . . . . . . . . 27 127 9.2. Apex aliasing . . . . . . . . . . . . . . . . . . . . . . 28 128 9.3. Parameter binding . . . . . . . . . . . . . . . . . . . . 28 129 9.4. Non-HTTPS uses . . . . . . . . . . . . . . . . . . . . . 29 130 10. Interaction with other standards . . . . . . . . . . . . . . 29 131 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 132 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 133 12.1. SVCB RRType . . . . . . . . . . . . . . . . . . . . . . 30 134 12.2. HTTPS RRType . . . . . . . . . . . . . . . . . . . . . . 30 135 12.3. New registry for Service Parameters . . . . . . . . . . 31 136 12.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . 31 137 12.3.2. Initial contents . . . . . . . . . . . . . . . . . . 31 138 12.4. Registry updates . . . . . . . . . . . . . . . . . . . . 32 139 13. Acknowledgments and Related Proposals . . . . . . . . . . . . 33 140 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 141 14.1. Normative References . . . . . . . . . . . . . . . . . . 33 142 14.2. Informative References . . . . . . . . . . . . . . . . . 36 143 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 37 144 Appendix A. Decoding text in zone files . . . . . . . . . . . . 37 145 A.1. Decoding a value list . . . . . . . . . . . . . . . . . . 37 147 Appendix B. Comparison with alternatives . . . . . . . . . . . . 38 148 B.1. Differences from the SRV RR type . . . . . . . . . . . . 38 149 B.2. Differences from the proposed HTTP record . . . . . . . . 39 150 B.3. Differences from the proposed ANAME record . . . . . . . 39 151 B.4. Comparison with separate RR types for AliasMode and 152 ServiceMode . . . . . . . . . . . . . . . . . . . . . . . 39 153 Appendix C. Change history . . . . . . . . . . . . . . . . . . . 40 154 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 156 1. Introduction 158 The SVCB and HTTPS RRs provide clients with complete instructions for 159 access to a service. This information enables improved performance 160 and privacy by avoiding transient connections to a sub-optimal 161 default server, negotiating a preferred protocol, and providing 162 relevant public keys. 164 For example, when clients need to make a connection to fetch 165 resources associated with an HTTPS URI, they currently resolve only A 166 and/or AAAA records for the origin hostname. This is adequate for 167 services that use basic HTTPS (fixed port, no QUIC, no [ECH]). Going 168 beyond basic HTTPS confers privacy, performance, and operational 169 advantages, but it requires the client to learn additional 170 information, and it is highly desirable to minimize the number of 171 round-trips and lookups required to learn this additional 172 information. 174 The SVCB and HTTPS RRs also help when the operator of a service 175 wishes to delegate operational control to one or more other domains, 176 e.g. delegating the origin "https://example.com" to a service 177 operator endpoint at "svc.example.net". While this case can 178 sometimes be handled by a CNAME, that does not cover all use-cases. 179 CNAME is also inadequate when the service operator needs to provide a 180 bound collection of consistent configuration parameters through the 181 DNS (such as network location, protocol, and keying information). 183 This document first describes the SVCB RR as a general-purpose 184 resource record that can be applied directly and efficiently to a 185 wide range of services (Section 2). The HTTPS RR is then defined as 186 a special case of SVCB that improves efficiency and convenience for 187 use with HTTPS (Section 7) by avoiding the need for an Attrleaf label 188 [Attrleaf] (Section 7.1). Other protocols with similar needs may 189 follow the pattern of HTTPS and assign their own SVCB-compatible RR 190 types. 192 All behaviors described as applying to the SVCB RR also apply to the 193 HTTPS RR unless explicitly stated otherwise. Section 7 describes 194 additional behaviors specific to the HTTPS RR. Apart from Section 7 195 and introductory examples, much of this document refers only to the 196 SVCB RR, but those references should be taken to apply to SVCB, 197 HTTPS, and any future SVCB-compatible RR types. 199 The SVCB RR has two modes: 1) "AliasMode" simply delegates 200 operational control for a resource; 2) "ServiceMode" binds together 201 configuration information for a service endpoint. ServiceMode 202 provides additional key=value parameters within each RDATA set. 204 TO BE REMOVED: If we use this for providing configuration for DNS 205 authorities, it is likely we'd specify a distinct "NS2" RR type that 206 is an instantiation of SVCB for authoritative nameserver delegation 207 and parameter specification, similar to HTTPS. See [I-D.tapril-ns2] 208 as one example. 210 1.1. Goals of the SVCB RR 212 The goal of the SVCB RR is to allow clients to resolve a single 213 additional DNS RR in a way that: 215 o Provides alternative endpoints that are authoritative for the 216 service, along with parameters associated with each of these 217 endpoints. 219 o Does not assume that all alternative endpoints have the same 220 parameters or capabilities, or are even operated by the same 221 entity. This is important as DNS does not provide any way to tie 222 together multiple RRs for the same name. For example, if 223 www.example.com is a CNAME alias that switches between one of 224 three CDNs or hosting environments, successive queries for that 225 name may return records that correspond to different environments. 227 o Enables CNAME-like functionality at a zone apex (such as 228 "example.com") for participating protocols, and generally enables 229 delegation of operational authority for an origin within the DNS 230 to an alternate name. 232 Additional goals specific to HTTPS RRs and the HTTPS use-case 233 include: 235 o Connect directly to HTTP3 (QUIC transport) alternative endpoints 236 [HTTP3] 238 o Obtain the Encrypted ClientHello [ECH] keys associated with an 239 alternative endpoint 241 o Support non-default TCP and UDP ports 242 o Enable SRV-like benefits (e.g. apex delegation, as mentioned 243 above) for HTTP(S), where SRV [SRV] has not been widely adopted 245 o Provide an HSTS-like indication [HSTS] signaling that the HTTPS 246 scheme should be used instead of HTTP for this request (see 247 Section 7.5). 249 1.2. Overview of the SVCB RR 251 This subsection briefly describes the SVCB RR in a non-normative 252 manner. (As mentioned above, this all applies equally to the HTTPS 253 RR which shares the same encoding, format, and high-level semantics.) 255 The SVCB RR has two modes: AliasMode, which aliases a name to another 256 name, and ServiceMode, which provides connection information bound to 257 a service endpoint domain. Placing both forms in a single RR type 258 allows clients to fetch the relevant information with a single query. 260 The SVCB RR has two mandatory fields and one optional. The fields 261 are: 263 1. SvcPriority: The priority of this record (relative to others, 264 with lower values preferred). A value of 0 indicates AliasMode. 265 (Described in Section 2.4.3.) 267 2. TargetName: The domain name of either the alias target (for 268 AliasMode) or the alternative endpoint (for ServiceMode). 270 3. SvcParams (optional): A list of key=value pairs describing the 271 alternative endpoint at TargetName (only used in ServiceMode and 272 otherwise ignored). Described in Section 2.1. 274 Cooperating DNS recursive resolvers will perform subsequent record 275 resolution (for SVCB, A, and AAAA records) and return them in the 276 Additional Section of the response. Clients either use responses 277 included in the additional section returned by the recursive resolver 278 or perform necessary SVCB, A, and AAAA record resolutions. DNS 279 authoritative servers can attach in-bailiwick SVCB, A, AAAA, and 280 CNAME records in the Additional Section to responses for a SVCB 281 query. 283 In ServiceMode, the SvcParams of the SVCB RR provide an extensible 284 data model for describing alternative endpoints that are 285 authoritative for the origin, along with parameters associated with 286 each of these alternative endpoints. 288 For the HTTPS use-case, the HTTPS RR enables many of the benefits of 289 Alt-Svc [AltSvc] without waiting for a full HTTP connection 290 initiation (multiple roundtrips) before learning of the preferred 291 alternative, and without necessarily revealing the user's intended 292 destination to all entities along the network path. 294 1.3. Parameter for Encrypted ClientHello 296 This document also defines a parameter for Encrypted ClientHello 297 [ECH] keys. See Section 8. 299 1.4. Terminology 301 Our terminology is based on the common case where the SVCB record is 302 used to access a resource identified by a URI whose "authority" field 303 contains a DNS hostname as the "host". 305 o The "service" is the information source identified by the 306 "authority" and "scheme" of the URI, capable of providing access 307 to the resource. For HTTPS URIs, the "service" corresponds to an 308 HTTPS "origin" [RFC6454]. 310 o The "service name" is the "host" portion of the authority. 312 o The "authority endpoint" is the authority's hostname and a port 313 number implied by the scheme or specified in the URI. 315 o An "alternative endpoint" is a hostname, port number, and other 316 associated instructions to the client on how to reach an instance 317 of service. 319 Additional DNS terminology intends to be consistent with [DNSTerm]. 321 SVCB is a contraction of "service binding". The SVCB RR, HTTPS RR, 322 and future RR types that share SVCB's format and registry are 323 collectively known as SVCB-compatible RR types. 325 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 326 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 327 "OPTIONAL" in this document are to be interpreted as described in BCP 328 14 [RFC2119] [RFC8174] when, and only when, they appear in all 329 capitals, as shown here. 331 2. The SVCB record type 333 The SVCB DNS resource record (RR) type (RR type 64) is used to locate 334 alternative endpoints for a service. 336 The algorithm for resolving SVCB records and associated address 337 records is specified in Section 3. 339 Other SVCB-compatible resource record types can also be defined as- 340 needed. In particular, the HTTPS RR (RR type 65) provides special 341 handling for the case of "https" origins as described in Section 7. 343 SVCB RRs are extensible by a list of SvcParams, which are pairs 344 consisting of a SvcParamKey and a SvcParamValue. Each SvcParamKey 345 has a presentation name and a registered number. Values are in a 346 format specific to the SvcParamKey. Their definition should specify 347 both their presentation format and wire encoding (e.g., domain names, 348 binary data, or numeric values). The initial SvcParamKeys and 349 formats are defined in Section 6. 351 2.1. Zone file presentation format 353 The presentation format of the record is: 355 Name TTL IN SVCB SvcPriority TargetName SvcParams 357 The SVCB record is defined specifically within the Internet ("IN") 358 Class ([RFC1035]). 360 SvcPriority is a number in the range 0-65535, TargetName is a domain 361 name, and the SvcParams are a whitespace-separated list, with each 362 SvcParam consisting of a SvcParamKey=SvcParamValue pair or a 363 standalone SvcParamKey. SvcParamKeys are subject to IANA control 364 (Section 12.3). 366 Each SvcParamKey SHALL appear at most once in the SvcParams. In 367 presentation format, SvcParamKeys are lower-case alphanumeric 368 strings. Key names should contain 1-63 characters from the ranges 369 "a"-"z", "0"-"9", and "-". In ABNF [RFC5234], 371 alpha-lc = %x61-7A ; a-z 372 SvcParamKey = 1*63(alpha-lc / DIGIT / "-") 373 SvcParam = SvcParamKey ["=" SvcParamValue] 374 SvcParamValue = char-string 375 value = *OCTET 377 The definition of each SvcParamKey indicates that its SvcParamValue 378 is empty, single-valued, or multi-valued. To parse a single-valued 379 SvcParam, the parser applies the character-string decoding algorithm 380 (Appendix A), producing a "value", and then performs key-specific 381 processing to validate the input and produce the wire-format 382 encoding. To parse a multi-valued SvcParam, the parser applies the 383 value-list decoding algorithm to the "char-string" (Appendix A.1), 384 splitting on unescaped commas to produce a list of zero or more 385 values. 387 When the "=" is omitted, the "value" or value list is interpreted as 388 empty. 390 Unrecognized keys are represented in presentation format as 391 "keyNNNNN" where NNNNN is the numeric value of the key type without 392 leading zeros. SvcParams in this form are always treated as single- 393 valued, and the decoded "value" SHALL be used as its wire format 394 encoding. 396 SvcParams in presentation format MAY appear in any order, but keys 397 MUST NOT be repeated. 399 2.2. RDATA wire format 401 The RDATA for the SVCB RR consists of: 403 o a 2 octet field for SvcPriority as an integer in network byte 404 order. 406 o the uncompressed, fully-qualified TargetName, represented as a 407 sequence of length-prefixed labels as in Section 3.1 of [RFC1035]. 409 o the SvcParams, consuming the remainder of the record (so smaller 410 than 65535 octets and constrained by the RDATA and DNS message 411 sizes). 413 When the list of SvcParams is non-empty (ServiceMode), it contains a 414 series of SvcParamKey=SvcParamValue pairs, represented as: 416 o a 2 octet field containing the SvcParamKey as an integer in 417 network byte order. (See Section 12.3.2 for the defined values.) 419 o a 2 octet field containing the length of the SvcParamValue as an 420 integer between 0 and 65535 in network byte order (but constrained 421 by the RDATA and DNS message sizes). 423 o an octet string of this length whose contents are in a format 424 determined by the SvcParamKey. 426 SvcParamKeys SHALL appear in increasing numeric order. 428 Clients MUST consider an RR malformed if: 430 o the parser reaches the end of the RDATA while parsing the 431 SvcParams. 433 o SvcParamKeys are not in strictly increasing numeric order. 435 o the SvcParamValue for an SvcParamKey does not have the expected 436 format. 438 Note that the second condition implies that there are no duplicate 439 SvcParamKeys. 441 If any RRs are malformed, the client MUST reject the entire RRSet and 442 fall back to non-SVCB connection establishment. 444 2.3. SVCB owner names 446 When querying the SVCB RR, a service is translated into a QNAME by 447 prepending the service name with a label indicating the scheme, 448 prefixed with an underscore, resulting in a domain name like 449 "_examplescheme.api.example.com.". 451 Protocol mapping documents MAY specify additional underscore-prefixed 452 labels to be prepended. For schemes that specify a port 453 (Section 3.2.3 of [URI]), one reasonable possibility is to prepend 454 the indicated port number (or the default if no port number is 455 specified). We term this behavior "Port Prefix Naming", and use it 456 in the examples throughout this document. 458 See Section 7.1 for the HTTPS RR behavior. 460 When a prior CNAME or SVCB record has aliased to a SVCB record, each 461 RR shall be returned under its own owner name. 463 Note that none of these forms alter the origin or authority for 464 validation purposes. For example, TLS clients MUST continue to 465 validate TLS certificates for the original service name. 467 As an example, the owner of example.com could publish this record: 469 _8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net. 471 to indicate that "foo://api.example.com:8443" is aliased to 472 "svc4.example.net". The owner of example.net, in turn, could publish 473 this record: 475 svc4.example.net. 7200 IN SVCB 3 svc4.example.net. ( 476 alpn="bar" port="8004" echconfig="..." ) 478 to indicate that these services are served on port number 8004, which 479 supports the protocol "bar" and its associated transport in addition 480 to the default transport protocol for "foo://". 482 (Parentheses are used to ignore a line break ([RFC1035] 483 Section 5.1).) 485 2.4. Modes 487 When SvcPriority is 0 the SVCB record is in AliasMode. Otherwise, it 488 is in ServiceMode. 490 Within a SVCB RRSet, all RRs SHOULD have the same Mode. If an RRSet 491 contains a record in AliasMode, the recipient MUST ignore any 492 ServiceMode records in the set. 494 2.4.1. AliasMode 496 In AliasMode, the SVCB record aliases a service to a TargetName. 497 SVCB RRSets SHOULD only have a single resource record in AliasMode. 498 If multiple are present, clients or recursive resolvers SHOULD pick 499 one at random. 501 The primary purpose of AliasMode is to allow aliasing at the zone 502 apex, where CNAME is not allowed. In AliasMode, TargetName MUST be 503 the name of a domain that has SVCB, AAAA, or A records. It MUST NOT 504 be equal to the owner name, as this would cause a loop. 506 For example, the operator of foo://example.com:8080 could point 507 requests to a service operating at foosvc.example.net by publishing: 509 _8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net. 511 Using AliasMode maintains a separation of concerns: the owner of 512 foosvc.example.net can add or remove ServiceMode SVCB records without 513 requiring a corresponding change to example.com. Note that if 514 foosvc.example.net promises to always publish a SVCB record, this 515 AliasMode record can be replaced by a CNAME, which would likely 516 improve performance. 518 AliasMode is especially useful for SVCB-compatible RR types that do 519 not require an underscore prefix, such as the HTTPS RR type. For 520 example, the operator of https://example.com could point requests to 521 a server at svc.example.net by publishing this record at the zone 522 apex: 524 example.com. 3600 IN HTTPS 0 svc.example.net. 526 Note that the SVCB record's owner name MAY be the canonical name of a 527 CNAME record, and the TargetName MAY be the owner of a CNAME record. 528 Clients and recursive resolvers MUST follow CNAMEs as normal. 530 To avoid unbounded alias chains, clients and recursive resolvers MUST 531 impose a limit on the total number of SVCB aliases they will follow 532 for each resolution request. This limit MUST NOT be zero, i.e. 533 implementations MUST be able to follow at least one AliasMode record. 534 The exact value of this limit is left to implementations. 536 For compatibility and performance, zone owners SHOULD NOT configure 537 their zones to require following multiple AliasMode records. 539 As legacy clients will not know to use this record, service operators 540 will likely need to retain fallback AAAA and A records alongside this 541 SVCB record, although in a common case the target of the SVCB record 542 might offer better performance, and therefore would be preferable for 543 clients implementing this specification to use. 545 AliasMode records only apply to queries for the specific RR type. 546 For example, a SVCB record cannot alias to an HTTPS record, nor vice- 547 versa. 549 2.4.2. ServiceMode 551 In ServiceMode, the TargetName and SvcParams within each resource 552 record associate an alternative endpoint for the service with its 553 connection parameters. 555 Each protocol scheme that uses SVCB MUST define a protocol mapping 556 that explains how SvcParams are applied for connections of that 557 scheme. Unless specified otherwise by the protocol mapping, clients 558 MUST ignore any SvcParam that they do not recognize. 560 2.4.3. SvcPriority 562 RRSets are explicitly unordered collections, so the SvcPriority field 563 is used to impose an ordering on SVCB RRs. SVCB RRs with a smaller 564 SvcPriority value SHOULD be given preference over RRs with a larger 565 SvcPriority value. 567 When receiving an RRSet containing multiple SVCB records with the 568 same SvcPriority value, clients SHOULD apply a random shuffle within 569 a priority level to the records before using them, to ensure uniform 570 load-balancing. 572 2.5. Special handling of "." in TargetName 574 If TargetName has the value "." (represented in the wire format as a 575 zero-length label), special rules apply. 577 2.5.1. AliasMode 579 For AliasMode SVCB RRs, a TargetName of "." indicates that the 580 service is not available or does not exist. This indication is 581 advisory: clients encountering this indication MAY ignore it and 582 attempt to connect without the use of SVCB. 584 2.5.2. ServiceMode 586 For ServiceMode SVCB RRs, if TargetName has the value ".", then the 587 owner name of this record MUST be used as the effective TargetName. 589 For example, in the following example "svc2.example.net" is the 590 effective TargetName: 592 example.com. 7200 IN HTTPS 0 svc.example.net. 593 svc.example.net. 7200 IN CNAME svc2.example.net. 594 svc2.example.net. 7200 IN HTTPS 1 . port=8002 echconfig="..." 595 svc2.example.net. 300 IN A 192.0.2.2 596 svc2.example.net. 300 IN AAAA 2001:db8::2 598 3. Client behavior 600 A SVCB-aware client selects an endpoint for a service using the 601 following procedure: 603 1. Let $ADDR_QNAME be the service name. Let $SVCB_QNAME be the 604 service name plus appropriate prefixes for the scheme (see 605 Section 2.3). 607 2. In parallel, issue AAAA/A queries for $ADDR_QNAME and a SVCB 608 query for $SVCB_QNAME. The answers for these may or may not 609 include CNAME pointers before reaching one or more of these 610 records. 612 3. If an AliasMode SVCB record is returned for $SVCB_QNAME, clients 613 MUST set $ADDR_QNAME and $SVCB_QNAME to its TargetName (without 614 additional prefixes) and loop back to step 2, subject to chain 615 length limits and loop detection heuristics (see Section 3.1). 617 4. If one or more ServiceMode records are returned for $SVCB_QNAME, 618 clients SHOULD select the highest-priority compatible record with 619 acceptable parameters. This TargetName and SvcParams represent 620 the preferred endpoint. If connection to this endpoint fails, 621 the client MAY try to connect using values from a lower-priority 622 record. If all attempts fail, clients SHOULD go to step 5. 624 5. Try to use the endpoint consisting of $ADDR_QNAME, the authority 625 endpoint's port number, and no SvcParams. 627 6. If all of the above connection attempts fail, clients MAY connect 628 to the authority endpoint. 630 This procedure does not rely on any recursive or authoritative DNS 631 server to comply with this specification or have any awareness of 632 SVCB. 634 When selecting between AAAA and A records to use, clients may use an 635 approach such as Happy Eyeballs [HappyEyeballsV2]. 637 Some important optimizations are discussed in Section 5 to avoid 638 additional latency in comparison to ordinary AAAA/A lookups. 640 3.1. Handling resolution failures 642 If a SVCB query results in a SERVFAIL error, transport error, or 643 timeout, and DNS exchanges between the client and the recursive 644 resolver are cryptographically protected (e.g. using TLS [DoT] or 645 HTTPS [DoH]), the client SHOULD NOT fall back to $ADDR_QNAME or the 646 authority endpoint (steps 5 and 6 above). Otherwise, an active 647 attacker could mount a downgrade attack by denying the user access to 648 the SvcParams. 650 A SERVFAIL error can occur if the domain is DNSSEC-signed, the 651 recursive resolver is DNSSEC-validating, and the attacker is between 652 the recursive resolver and the authoritative DNS server. A transport 653 error or timeout can occur if an active attacker between the client 654 and the recursive resolver is selectively dropping SVCB queries or 655 responses, based on their size or other observable patterns. 657 Similarly, if the client enforces DNSSEC validation on A/AAAA 658 responses, it SHOULD NOT fall back to steps 5 or 6 if the SVCB 659 response fails to validate. 661 If the client is unable to complete SVCB resolution due to its chain 662 length limit, the client SHOULD fall back to the authority endpoint, 663 as if the origin's SVCB record did not exist. 665 3.2. Clients using a Proxy 667 Clients using a domain-oriented transport proxy like HTTP CONNECT 668 ([RFC7231] Section 4.3.6) or SOCKS5 ([RFC1928]) have the option to 669 use named destinations, in which case the client does not perform any 670 A or AAAA queries for destination domains. If the client is using 671 named destinations with a proxy that does not provide SVCB query 672 capability (e.g. through an affiliated DNS resolver), the client 673 would have to perform SVCB queries though a separate resolver. This 674 might disclose the client's destinations to an additional party, 675 creating privacy concerns. If these concerns apply, the client 676 SHOULD disable SVCB resolution. 678 If the client does use SVCB and named destinations, the client SHOULD 679 follow the standard SVCB resolution process, selecting the smallest- 680 SvcPriority option that is compatible with the client and the proxy. 681 The client SHOULD provide the final TargetName and port to the proxy, 682 which will perform any required A and AAAA lookups. 684 Providing the proxy with the final TargetName has several benefits: 686 o It allows the client to use the SvcParams, if present, which is 687 only usable with a specific TargetName. The SvcParams may include 688 information that enhances performance (e.g. alpn) and privacy 689 (e.g. echconfig). 691 o It allows the service to delegate the apex domain. 693 o It allows the proxy to select between IPv4 and IPv6 addresses for 694 the server according to its configuration, and receive addresses 695 based on its network geolocation. 697 4. DNS Server Behavior 699 4.1. Authoritative servers 701 When replying to a SVCB query, authoritative DNS servers SHOULD 702 return A, AAAA, and SVCB records in the Additional Section for any 703 in-bailiwick TargetNames. If the zone is signed, the server SHOULD 704 also include positive or negative DNSSEC responses for these records 705 in the Additional section. 707 4.2. Recursive resolvers 709 Recursive resolvers that are aware of SVCB SHOULD help the client to 710 execute the procedure in Section 3 with minimum overall latency, by 711 incorporating additional useful information into the response. For 712 the initial SVCB record query, this is just the normal response 713 construction process (i.e. unknown RR type resolution under 714 [RFC3597]). For followup resolutions performed during this 715 procedure, we define incorporation as adding all useful RRs from the 716 response to the Additional section without altering the response 717 code. 719 Upon receiving a SVCB query, recursive resolvers SHOULD start with 720 the standard resolution procedure, and then follow this procedure to 721 construct the full response to the stub resolver: 723 1. Incorporate the results of SVCB resolution. If the chain length 724 limit has been reached, terminate successfully (i.e. a NOERROR 725 response). 727 2. If any of the resolved SVCB records are in AliasMode, choose one 728 of them at random, and resolve SVCB, A, and AAAA records for its 729 TargetName. 731 * If any SVCB records are resolved, go to step 1. 733 * Otherwise, incorporate the results of A and AAAA resolution, 734 and terminate. 736 3. All the resolved SVCB records are in ServiceMode. Resolve A and 737 AAAA queries for each TargetName (or for the owner name if 738 TargetName is "."), incorporate all the results, and terminate. 740 In this procedure, "resolve" means the resolver's ordinary recursive 741 resolution procedure, as if processing a query for that RRSet. This 742 includes following any aliases that the resolver would ordinarily 743 follow (e.g. CNAME, DNAME [DNAME]). 745 See Section 5.2 for possible optimizations of this procedure. 747 4.3. General requirements 749 Recursive resolvers SHOULD treat the SvcParams portion of the SVCB RR 750 as opaque and SHOULD NOT try to alter their behavior based on its 751 contents. 753 When responding to a query that includes the DNSSEC OK bit 754 ([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers 755 MUST accompany each RRSet in the Additional section with the same 756 DNSSEC-related records that they would send when providing that RRSet 757 as an Answer (e.g. RRSIG, NSEC, NSEC3). 759 5. Performance optimizations 761 For optimal performance (i.e. minimum connection setup time), clients 762 SHOULD issue address (AAAA and/or A) and SVCB queries simultaneously, 763 and SHOULD implement a client-side DNS cache. Responses in the 764 Additional section of a SVCB response SHOULD be placed in cache 765 before performing any followup queries. With these optimizations in 766 place, and conforming DNS servers, using SVCB does not add network 767 latency to connection setup. 769 5.1. Optimistic pre-connection and connection reuse 771 If an address response arrives before the corresponding SVCB 772 response, the client MAY initiate a connection as if the SVCB query 773 returned NODATA, but MUST NOT transmit any information that could be 774 altered by the SVCB response until it arrives. For example, a TLS 775 ClientHello can be altered by the "echconfig" value of a SVCB 776 response (Section 6.3). Clients implementing this optimization 777 SHOULD wait for 50 milliseconds before starting optimistic pre- 778 connection, as per the guidance in [HappyEyeballsV2]. 780 An SVCB record is consistent with a connection if the client would 781 attempt an equivalent connection when making use of that record. If 782 a SVCB record is consistent with an active or in-progress connection 783 C, the client MAY prefer that record and use C as its connection. 784 For example, suppose the client receives this SVCB RRSet for a 785 protocol that uses TLS over TCP: 787 _1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. ( 788 echconfig="111..." ipv6hint=2001:db8::1 port=1234 ... ) 789 SVCB 2 svc2.example.net. ( 790 echconfig="222..." ipv6hint=2001:db8::2 port=1234 ... ) 792 If the client has an in-progress TCP connection to 793 "[2001:db8::2]:1234", it MAY proceed with TLS on that connection 794 using "echconfig="222..."", even though the other record in the RRSet 795 has higher priority. 797 If none of the SVCB records are consistent with any active or in- 798 progress connection, clients must proceed as described in Step 3 of 799 the procedure in Section 3. 801 5.2. Generating and using incomplete responses 803 When following the procedure in Section 4.2, recursive resolvers MAY 804 terminate the procedure early and produce a reply that omits some of 805 the associated RRSets. This is REQUIRED when the chain length limit 806 is reached (Section 4.2 step 1), but might also be appropriate when 807 the maximum response size is reached, or when responding before fully 808 chasing dependencies would improve performance. When omitting 809 certain RRSets, recursive resolvers SHOULD prioritize information for 810 smaller-SvcPriority records. 812 As discussed in Section 3, clients MUST be able to fetch additional 813 information that is required to use a SVCB record, if it is not 814 included in the initial response. As a performance optimization, if 815 some of the SVCB records in the response can be used without 816 requiring additional DNS queries, the client MAY prefer those 817 records, regardless of their priorities. 819 5.3. Structuring zones for performance 821 To avoid a delay for clients using a nonconforming recursive 822 resolver, domain owners SHOULD minimize the use of AliasMode records, 823 and choose TargetName to be a domain for which the client will have 824 already issued address queries (see Section 3). For 825 foo://foo.example.com:8080, this might look like: 827 ; Origin zone 828 foo.example.com. 3600 IN CNAME foosvc.example.net. 829 _8080._foo.foo.example.com. 3600 IN CNAME foosvc.example.net. 830 ; Service provider zone 831 foosvc.example.net. 3600 IN SVCB 1 . key65333=... 832 foosvc.example.net. 300 IN AAAA 2001:db8::1 834 Domain owners SHOULD avoid using a SvcDomainName that is below a 835 DNAME, as this is likely unnecessary and makes responses slower and 836 larger. 838 6. Initial SvcParamKeys 840 A few initial SvcParamKeys are defined here. These keys are useful 841 for HTTPS, and most are applicable to other protocols as well. 843 6.1. "alpn" and "no-default-alpn" 845 The "alpn" and "no-default-alpn" SvcParamKeys together indicate the 846 set of Application Layer Protocol Negotation (ALPN) protocol 847 identifiers [ALPN] and associated transport protocols supported by 848 this service endpoint. 850 As with Alt-Svc [AltSvc], the ALPN protocol identifier is used to 851 identify the application protocol and associated suite of protocols 852 supported by the endpoint (the "protocol suite"). Clients filter the 853 set of ALPN identifiers to match the protocol suites they support, 854 and this informs the underlying transport protocol used (such as 855 QUIC-over-UDP or TLS-over-TCP). 857 ALPNs are identified by their registered "Identification Sequence" 858 ("alpn-id"), which is a sequence of 1-255 octets. 860 alpn-id = 1*255OCTET 861 "alpn" is a multi-valued SvcParamKey. Each decoded value in the 862 "alpn" value list SHALL be an "alpn-id". The value list MUST NOT be 863 empty. 865 The wire format value for "alpn" consists of at least one "alpn-id" 866 prefixed by its length as a single octet, and these length-value 867 pairs are concatenated to form the SvcParamValue. These pairs MUST 868 exactly fill the SvcParamValue; otherwise, the SvcParamValue is 869 malformed. 871 For "no-default-alpn", the presentation and wire format values MUST 872 be empty. 874 Each scheme that uses this SvcParamKey defines a "default set" of 875 supported ALPNs, which SHOULD NOT be empty. To determine the set of 876 protocol suites supported by an endpoint (the "SVCB ALPN set"), the 877 client adds the default set to the list of "alpn-id"s unless the "no- 878 default-alpn" SvcParamKey is present. The presence of an ALPN 879 protocol in the SVCB ALPN set indicates that this service endpoint, 880 described by TargetName and the other parameters (e.g. "port") offers 881 service with the protocol suite associated with this ALPN protocol. 883 ALPN protocol names that do not uniquely identify a protocol suite 884 (e.g. an Identification Sequence that can be used with both TLS and 885 DTLS) are not compatible with this SvcParamKey and MUST NOT be 886 included in the SVCB ALPN set. 888 To establish a connection to the endpoint, clients MUST 890 1. Let SVCB-ALPN-Intersection be the set of protocols in the SVCB 891 ALPN set that the client supports. 893 2. Let Intersection-Transports be the set of transports (e.g. TLS, 894 DTLS, QUIC) implied by the protocols in SVCB-ALPN-Intersection. 896 3. For each transport in Intersection-Transports, construct a 897 ProtocolNameList containing the Identification Sequences of all 898 the client's supported ALPN protocols for that transport, without 899 regard to the SVCB ALPN set. 901 For example, if the SVCB ALPN set is ["http/1.1", "h3"], and the 902 client supports HTTP/1.1, HTTP/2, and HTTP/3, the client could 903 attempt to connect using TLS over TCP with a ProtocolNameList of 904 ["http/1.1", "h2"], and could also attempt a connection using QUIC, 905 with a ProtocolNameList of ["h3"]. 907 Once the client has constructed a ClientHello, protocol negotiation 908 in that handshake proceeds as specified in [ALPN], without regard to 909 the SVCB ALPN set. 911 With this procedure in place, an attacker who can modify DNS and 912 network traffic can prevent a successful transport connection, but 913 cannot otherwise interfere with ALPN protocol selection. This 914 procedure also ensures that each ProtocolNameList includes at least 915 one protocol from the SVCB ALPN set. 917 Clients SHOULD NOT attempt connection to a service endpoint whose 918 SVCB ALPN set does not contain any supported protocols. To ensure 919 consistency of behavior, clients MAY reject the entire SVCB RRSet and 920 fall back to basic connection establishment if all of the RRs 921 indicate "no-default-alpn", even if connection could have succeeded 922 using a non-default alpn. 924 For compatibility with clients that require default transports, zone 925 operators SHOULD ensure that at least one RR in each RRSet supports 926 the default transports. 928 6.2. "port" 930 The "port" SvcParamKey defines the TCP or UDP port that should be 931 used to reach this alternative endpoint. If this key is not present, 932 clients SHALL use the authority endpoint's port number. 934 The presentation "value" of the SvcParamValue is a single decimal 935 integer between 0 and 65535 in ASCII. Any other "value" (e.g. an 936 empty value) is a syntax error. To enable simpler parsing, this 937 SvcParam MUST NOT contain escape sequences. 939 The wire format of the SvcParamValue is the corresponding 2 octet 940 numeric value in network byte order. 942 If a port-restricting firewall is in place between some client and 943 the service endpoint, changing the port number might cause that 944 client to lose access to the service, so operators should exercise 945 caution when using this SvcParamKey to specify a non-default port. 947 6.3. "echconfig" 949 The SvcParamKey to enable Encrypted ClientHello (ECH) is "echconfig". 950 Its value is defined in Section 8. It is applicable to most TLS- 951 based protocols. 953 When publishing a record containing an "echconfig" parameter, the 954 publisher MUST ensure that all IP addresses of TargetName correspond 955 to servers that have access to the corresponding private key or are 956 authoritative for the public name. (See Section 7.2.2 of [ECH] for 957 more details about the public name.) This yields an anonymity set of 958 cardinality equal to the number of ECH-enabled server domains 959 supported by a given client-facing server. Thus, even with an 960 encrypted ClientHello, an attacker who can enumerate the set of ECH- 961 enabled domains supported by a client-facing server can guess the 962 correct SNI with probability at least 1/K, where K is the size of 963 this ECH-enabled server anonymity set. This probability may be 964 increased via traffic analysis or other mechanisms. 966 6.4. "ipv4hint" and "ipv6hint" 968 The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients 969 MAY use to reach the service. If A and AAAA records for TargetName 970 are locally available, the client SHOULD ignore these hints. 971 Otherwise, clients SHOULD perform A and/or AAAA queries for 972 TargetName as in Section 3, and clients SHOULD use the IP address in 973 those responses for future connections. Clients MAY opt to terminate 974 any connections using the addresses in hints and instead switch to 975 the addresses in response to the TargetName query. Failure to use A 976 and/or AAAA response addresses could negatively impact load balancing 977 or other geo-aware features and thereby degrade client performance. 979 Each decoded value in the value list SHALL be an IP address of the 980 appropriate family in standard textual format [RFC5952]. To enable 981 simpler parsing, this SvcParam MUST NOT contain escape sequences. 983 The wire format for each parameter is a sequence of IP addresses in 984 network byte order. Like an A or AAAA RRSet, the list of addresses 985 represents an unordered collection, and clients SHOULD pick addresses 986 to use in a random order. An empty list of addresses is invalid. 988 When selecting between IPv4 and IPv6 addresses to use, clients may 989 use an approach such as Happy Eyeballs [HappyEyeballsV2]. When only 990 "ipv4hint" is present, IPv6-only clients may synthesize IPv6 991 addresses as specified in [RFC7050] or ignore the "ipv4hint" key and 992 wait for AAAA resolution (Section 3). Recursive resolvers MUST NOT 993 perform DNS64 ([RFC6147]) on parameters within a SVCB record. For 994 best performance, server operators SHOULD include an "ipv6hint" 995 parameter whenever they include an "ipv4hint" parameter. 997 These parameters are intended to minimize additional connection 998 latency when a recursive resolver is not compliant with the 999 requirements in Section 4, and SHOULD NOT be included if most clients 1000 are using compliant recursive resolvers. When TargetName is the 1001 origin hostname or the owner name (which can be written as "."), 1002 server operators SHOULD NOT include these hints, because they are 1003 unlikely to convey any performance benefit. 1005 6.5. "mandatory" 1007 In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the 1008 RR will not function correctly for clients that ignore this 1009 SvcParamKey. Each SVCB protocol mapping SHOULD specify a set of keys 1010 that are "automatically mandatory", i.e. mandatory if they are 1011 present in an RR. The SvcParamKey "mandatory" is used to indicate 1012 any mandatory keys for this RR, in addition to any automatically 1013 mandatory keys that are present. 1015 A ServiceMode RR is considered "compatible" with a client if the 1016 client implements support for all its mandatory keys. If the SVCB 1017 RRSet contains no compatible RRs, the client will generally act as if 1018 the RRSet is empty. 1020 In presentation format, "mandatory" contains a list of one or more 1021 valid SvcParamKeys, either by their registered name or in the 1022 unknown-key format (Section 2.1). Keys MAY appear in any order, but 1023 MUST NOT appear more than once. Any listed keys MUST also appear in 1024 the SvcParams. For example, the following is a valid list of 1025 SvcParams: 1027 echconfig=... key65333=ex1 key65444=ex2 mandatory=key65444,echconfig 1029 In wire format, the keys are represented by their numeric values in 1030 network byte order, concatenated in ascending order. 1032 This SvcParamKey is always automatically mandatory, and MUST NOT 1033 appear in its own value list. Other automatically mandatory keys 1034 SHOULD NOT appear in the list either. (Including them wastes space 1035 and otherwise has no effect.) 1037 7. Using SVCB with HTTPS and HTTP 1039 Use of any protocol with SVCB requires a protocol-specific mapping 1040 specification. This section specifies the mapping for HTTPS and 1041 HTTP. 1043 To enable special handling for the HTTPS and HTTP use-cases, the 1044 HTTPS RR type is defined as a SVCB-compatible RR type, specific to 1045 the https and http schemes. Clients MUST NOT perform SVCB queries or 1046 accept SVCB responses for "https" or "http" schemes. 1048 The HTTPS RR wire format and presentation format are identical to 1049 SVCB, and both share the SvcParamKey registry. SVCB semantics apply 1050 equally to HTTPS RRs unless specified otherwise. The presentation 1051 format of the record is: 1053 Name TTL IN HTTPS SvcPriority TargetName SvcParams 1055 As with SVCB, the record is defined specifically within the Internet 1056 ("IN") Class [RFC1035]. 1058 All the SvcParamKeys defined in Section 6 are permitted for use in 1059 HTTPS RRs. The default set of ALPN IDs is the single value 1060 "http/1.1". The "automatically mandatory" keys (Section 6.5) are 1061 "port", "alpn", and "no-default-alpn". 1063 The presence of an HTTPS RR for an origin also indicates that all 1064 HTTP resources are available over HTTPS, as discussed in Section 7.5. 1065 This allows HTTPS RRs to apply to pre-existing "http" scheme URLs, 1066 while ensuring that the client uses a secure and authenticated HTTPS 1067 connection. 1069 The HTTPS RR parallels the concepts introduced in the HTTP 1070 Alternative Services proposed standard [AltSvc]. Clients and servers 1071 that implement HTTPS RRs are not required to implement Alt-Svc. 1073 7.1. Owner names for HTTPS RRs 1075 The HTTPS RR uses Port Prefix Naming (Section 2.3), with one 1076 modification: if the scheme is "https" and the port is 443, then the 1077 client's original QNAME is equal to the service name (i.e. the 1078 origin's hostname), without any prefix labels. 1080 By removing the Attrleaf labels [Attrleaf] used in SVCB, this 1081 construction enables offline DNSSEC signing of wildcard domains, 1082 which are commonly used with HTTPS. Reusing the service name also 1083 allows the targets of existing CNAME chains (e.g. CDN hosts) to 1084 start returning HTTPS RR responses without requiring origin domains 1085 to configure and maintain an additional delegation. 1087 Following of HTTPS AliasMode RRs and CNAME aliases is unchanged from 1088 SVCB. 1090 Clients always convert "http" URLs to "https" before performing an 1091 HTTPS RR query using the process described in Section 7.5, so domain 1092 owners MUST NOT publish HTTPS RRs with a prefix of "_http". 1094 Note that none of these forms alter the HTTPS origin or authority. 1095 For example, clients MUST continue to validate TLS certificate 1096 hostnames based on the origin. 1098 7.2. Relationship to Alt-Svc 1100 Publishing a ServiceMode HTTPS RR in DNS is intended to be similar to 1101 transmitting an Alt-Svc field value over HTTPS, and receiving an 1102 HTTPS RR is intended to be similar to receiving that field value over 1103 HTTPS. However, there are some differences in the intended client 1104 and server behavior. 1106 7.2.1. ALPN usage 1108 Unlike Alt-Svc Field Values, HTTPS RRs can contain multiple ALPN IDs, 1109 and clients are encouraged to offer additional ALPNs that they 1110 support (subject to security constraints). 1112 TO BE REMOVED: The ALPN semantics in [AltSvc] are ambiguous, and 1113 problematic in some interpretations. We should update [AltSvc] to 1114 give it well-defined semantics that match HTTPS RRs. 1116 7.2.2. Untrusted channel 1118 SVCB does not require or provide any assurance of authenticity. 1119 (DNSSEC signing and verification, which would provide such assurance, 1120 are OPTIONAL.) The DNS resolution process is treated as an untrusted 1121 channel that learns only the QNAME, and is prevented from mounting 1122 any attack beyond denial of service. 1124 Alt-Svc parameters that cannot be safely received in this model MUST 1125 NOT have a corresponding defined SvcParamKey. For example, there is 1126 no SvcParamKey corresponding to the Alt-Svc "persist" parameter, 1127 because this parameter is not safe to accept over an untrusted 1128 channel. 1130 7.2.3. TTL and granularity 1132 There is no SvcParamKey corresponding to the Alt-Svc "ma" (max age) 1133 parameter. Instead, server operators encode the expiration time in 1134 the DNS TTL. 1136 The appropriate TTL value will typically be similar to the "ma" value 1137 used for Alt-Svc, but may vary depending on the desired efficiency 1138 and agility. Some DNS caches incorrectly extend the lifetime of DNS 1139 records beyond the stated TTL, so server operators cannot rely on 1140 HTTPS RRs expiring on time. Shortening the TTL to compensate for 1141 incorrect caching is NOT RECOMMENDED, as this practice impairs the 1142 performance of correctly functioning caches and does not guarantee 1143 faster expiration from incorrect caches. Instead, server operators 1144 SHOULD maintain compatibility with expired records until they observe 1145 that nearly all connections have migrated to the new configuration. 1147 Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc 1148 Field Value specifically to the client. When using an HTTPS RR, 1149 groups of clients will necessarily receive the same SvcParams. 1150 Therefore, HTTPS RRs are not suitable for uses that require single- 1151 client granularity. 1153 7.3. Interaction with Alt-Svc 1155 Clients that do not implement support for Encrypted ClientHello MAY 1156 skip the HTTPS RR query if a usable Alt-Svc value is available in the 1157 local cache. If Alt-Svc connection fails, these clients SHOULD fall 1158 back to the HTTPS RR client connection procedure (Section 3). 1160 For clients that implement support for ECH, the interaction between 1161 HTTPS RRs and Alt-Svc is described in Section 8.1. 1163 This specification does not alter the DNS queries performed when 1164 connecting to an Alt-Svc hostname (typically A and/or AAAA only). 1166 7.4. Requiring Server Name Indication 1168 Clients MUST NOT use an HTTPS RR response unless the client supports 1169 TLS Server Name Indication (SNI) and indicate the origin name when 1170 negotiating TLS. This supports the conservation of IP addresses. 1172 Note that the TLS SNI (and also the HTTP "Host" or ":authority") will 1173 indicate the origin, not the TargetName. 1175 7.5. HTTP Strict Transport Security 1177 By publishing a usable HTTPS RR, the server operator indicates that 1178 all useful HTTP resources on that origin are reachable over HTTPS, 1179 similar to HTTP Strict Transport Security [HSTS]. 1181 Prior to making an "http" scheme request, the client SHOULD perform a 1182 lookup to determine if any HTTPS RRs exist for that origin. To do 1183 so, the client SHOULD construct a corresponding "https" URL as 1184 follows: 1186 1. Replace the "http" scheme with "https". 1188 2. If the "http" URL explicitly specifies port 80, specify port 443. 1190 3. Do not alter any other aspect of the URL. 1192 This construction is equivalent to Section 8.3 of [HSTS], point 5. 1194 If an HTTPS RR query for this "https" URL returns any AliasMode HTTPS 1195 RRs, or any compatible ServiceMode HTTPS RRs (see Section 6.5), the 1196 client SHOULD act as if it has received an HTTP "307 Temporary 1197 Redirect" redirect to this "https" URL. (Receipt of an incompatible 1198 ServiceMode RR does not trigger the redirect behavior.) Because 1199 HTTPS RRs are received over an often insecure channel (DNS), clients 1200 MUST NOT place any more trust in this signal than if they had 1201 received a 307 redirect over cleartext HTTP. 1203 When making an "https" scheme request to an origin with an HTTPS RR, 1204 either directly or via the above redirect, the client SHOULD 1205 terminate the connection if there are any errors with the underlying 1206 secure transport, such as errors in certificate validation. This 1207 aligns with Section 8.4 and Section 12.1 of [HSTS]. 1209 7.6. HTTP-based protocols 1211 We define an "HTTP-based protocol" as one that involves connecting to 1212 an "http:" or "https:" URL. When implementing an HTTP-based 1213 protocol, clients that use HTTPS RRs for HTTP SHOULD also use it for 1214 this URL. For example, clients that support HTTPS RRs and implement 1215 the altered WebSocket [WebSocket] opening handshake from the W3C 1216 Fetch specification [FETCH] SHOULD use HTTPS RRs for the 1217 "requestURL". 1219 An HTTP-based protocol MAY define its own SVCB mapping. Such 1220 mappings MAY be defined to take precedence over HTTPS RRs. 1222 8. SVCB/HTTPS RR parameter for ECH configuration 1224 The SVCB "echconfig" parameter is defined for conveying the ECH 1225 configuration of an alternative endpoint. In wire format, the value 1226 of the parameter is an ECHConfigs vector [ECH], including the 1227 redundant length prefix. In presentation format, the value is a 1228 single ECHConfigs encoded in Base64 [base64]. Base64 is used here to 1229 simplify integration with TLS server software. To enable simpler 1230 parsing, this SvcParam MUST NOT contain escape sequences. 1232 When ECH is in use, the TLS ClientHello is divided into an 1233 unencrypted "outer" and an encrypted "inner" ClientHello. The outer 1234 ClientHello is an implementation detail of ECH, and its contents are 1235 controlled by the ECHConfig in accordance with [ECH]. The inner 1236 ClientHello is used for establishing a connection to the service, so 1237 its contents may be influenced by other SVCB parameters. For 1238 example, the requirements on the ProtocolNameList in Section 6.1 1239 apply only to the inner ClientHello. Similarly, it is the inner 1240 ClientHello whose Server Name Indication identifies the desired 1241 service. 1243 8.1. Client behavior 1245 The general client behavior specified in Section 3 permits clients to 1246 retry connection with a less preferred alternative if the preferred 1247 option fails, including falling back to a direct connection if all 1248 SVCB options fail. This behavior is not suitable for ECH, because 1249 fallback would negate the privacy benefits of ECH. Accordingly, ECH- 1250 capable clients SHALL implement the following behavior for connection 1251 establishment: 1253 1. Perform connection establishment using HTTPS RRs as described in 1254 Section 3, but do not fall back to address records (steps 5 and 1255 6). If there are compatible HTTPS RRs, they all have an 1256 "echconfig" key, and attempts to connect to them all fail, 1257 terminate connection establishment. 1259 2. If the client implements Alt-Svc, try to connect using any 1260 entries from the Alt-Svc cache. 1262 3. Fall back to address records (steps 5 and 6 of Section 3) if 1263 necessary. 1265 As a latency optimization, clients MAY prefetch DNS records for later 1266 steps before they are needed. 1268 8.2. Deployment considerations 1270 An HTTPS RRSet containing some RRs with "echconfig" and some without 1271 is vulnerable to a downgrade attack. This configuration is NOT 1272 RECOMMENDED. Zone owners who do use such a mixed configuration 1273 SHOULD mark the RRs with "echconfig" as more preferred (i.e. smaller 1274 SvcPriority) than those without, in order to maximize the likelihood 1275 that ECH will be used in the absence of an active adversary. 1277 9. Examples 1279 9.1. Protocol enhancements 1281 Consider a simple zone of the form: 1283 simple.example. 300 IN A 192.0.2.1 1284 AAAA 2001:db8::1 1286 The domain owner could add this record: 1288 simple.example. 7200 IN HTTPS 1 . alpn=h3 ... 1290 to indicate that simple.example uses HTTPS, and supports QUIC in 1291 addition to HTTPS over TCP (an implicit default). The record could 1292 also include other information (e.g. non-standard port, ECH 1293 configuration). 1295 9.2. Apex aliasing 1297 Consider a zone that is using CNAME aliasing: 1299 $ORIGIN aliased.example. ; A zone that is using a hosting service 1300 ; Subdomain aliased to a high-performance server pool 1301 www 7200 IN CNAME pool.svc.example. 1302 ; Apex domain on fixed IPs because CNAME is not allowed at the apex 1303 @ 300 IN A 192.0.2.1 1304 IN AAAA 2001:db8::1 1306 With HTTPS RRs, the owner of aliased.example could alias the apex by 1307 adding one additional record: 1309 @ 7200 IN HTTPS 0 pool.svc.example. 1311 With this record in place, HTTPS-RR-aware clients will use the same 1312 server pool for aliased.example and www.aliased.example. (They will 1313 also upgrade to HTTPS on aliased.example.) Non-HTTPS-RR-aware 1314 clients will just ignore the new record. 1316 Similar to CNAME, HTTPS RRs have no impact on the origin name. When 1317 connecting, clients will continue to treat the authoritative origins 1318 as "https://www.aliased.example" and "https://aliased.example", 1319 respectively, and will validate TLS server certificates accordingly. 1321 9.3. Parameter binding 1323 Suppose that svc.example's default server pool supports HTTP/2, and 1324 it has deployed HTTP/3 on a new server pool with a different 1325 configuration. This can be expressed in the following form: 1327 $ORIGIN svc.example. ; A hosting provider. 1328 pool 7200 IN HTTPS 1 h3pool alpn=h2,h3 echconfig="123..." 1329 HTTPS 2 . alpn=h2 echconfig="abc..." 1330 pool 300 IN A 192.0.2.2 1331 AAAA 2001:db8::2 1332 h3pool 300 IN A 192.0.2.3 1333 AAAA 2001:db8::3 1335 This configuration is entirely compatible with the "Apex aliasing" 1336 example, whether the client supports HTTPS RRs or not. If the client 1337 does support HTTPS RRs, all connections will be upgraded to HTTPS, 1338 and clients will use HTTP/3 if they can. Parameters are "bound" to 1339 each server pool, so each server pool can have its own protocol, ECH 1340 configuration, etc. 1342 9.4. Non-HTTPS uses 1344 For services other than HTTPS, the SVCB RR and an Attrleaf label 1345 [Attrleaf] will be used. For example, to reach an example resource 1346 of "baz://api.example.com:8765", the following SVCB record would be 1347 used to alias it to "svc4-baz.example.net." which in-turn could 1348 return AAAA/A records and/or SVCB records in ServiceMode: 1350 _8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net. 1352 HTTPS RRs use similar Attrleaf labels if the origin contains a non- 1353 default port. 1355 10. Interaction with other standards 1357 This standard is intended to reduce connection latency and improve 1358 user privacy. Server operators implementing this standard SHOULD 1359 also implement TLS 1.3 [RFC8446] and OCSP Stapling [RFC6066], both of 1360 which confer substantial performance and privacy benefits when used 1361 in combination with SVCB records. 1363 To realize the greatest privacy benefits, this proposal is intended 1364 for use over a privacy-preserving DNS transport (like DNS over TLS 1365 [DoT] or DNS over HTTPS [DoH]). However, performance improvements, 1366 and some modest privacy improvements, are possible without the use of 1367 those standards. 1369 Any specification for use of SVCB with a protocol MUST have an entry 1370 for its scheme under the SVCB RR type in the IANA DNS Underscore 1371 Global Scoped Entry Registry [Attrleaf]. The scheme SHOULD have an 1372 entry in the IANA URI Schemes Registry [RFC7595]. The scheme SHOULD 1373 have a defined specification for use with SVCB. 1375 11. Security Considerations 1377 SVCB/HTTPS RRs are intended for distribution over untrusted channels, 1378 and clients are REQUIRED to verify that the alternative endpoint is 1379 authoritative for the service (similar to Section 2.1 of [AltSvc]). 1380 Therefore, DNSSEC signing and validation are OPTIONAL for publishing 1381 and using SVCB and HTTPS RRs. 1383 Clients MUST ensure that their DNS cache is partitioned for each 1384 local network, or flushed on network changes, to prevent a local 1385 adversary in one network from implanting a forged DNS record that 1386 allows them to track users or hinder their connections after they 1387 leave that network. 1389 An attacker who can prevent SVCB resolution can deny clients any 1390 associated security benefits. A hostile recursive resolver can 1391 always deny service to SVCB queries, but network intermediaries can 1392 often prevent resolution as well, even when the client and recursive 1393 resolver validate DNSSEC and use a secure transport. These downgrade 1394 attacks can prevent the HTTPS upgrade provided by the HTTPS RR 1395 (Section 7.5), and disable the encryption enabled by the echconfig 1396 SvcParamKey (Section 8). To prevent downgrades, Section 3.1 1397 recommends that clients abandon the connection attempt when such an 1398 attack is detected. 1400 A hostile DNS intermediary might forge AliasForm "." records 1401 (Section 2.5.1) as a way to block clients from accessing particular 1402 services. Such an adversary could already block entire domains by 1403 forging erroneous responses, but this mechanism allows them to target 1404 particular protocols or ports within a domain. Clients that might be 1405 subject to such attacks SHOULD ignore AliasForm "." records. 1407 12. IANA Considerations 1409 12.1. SVCB RRType 1411 This document defines a new DNS RR type, SVCB, whose value 64 has 1412 been allocated by IANA from the "Resource Record (RR) TYPEs" 1413 subregistry of the "Domain Name System (DNS) Parameters" registry: 1415 Type: SVCB 1417 Value: 64 1419 Meaning: General Purpose Service Endpoints 1421 Reference: This document 1423 12.2. HTTPS RRType 1425 This document defines a new DNS RR type, HTTPS, whose value 65 has 1426 been allocated by IANA from the "Resource Record (RR) TYPEs" 1427 subregistry of the "Domain Name System (DNS) Parameters" registry: 1429 Type: HTTPS 1431 Value: 65 1433 Meaning: HTTPS Specific Service Endpoints 1434 Reference: This document 1436 12.3. New registry for Service Parameters 1438 The "Service Binding (SVCB) Parameter Registry" defines the namespace 1439 for parameters, including string representations and numeric 1440 SvcParamKey values. This registry is shared with other SVCB- 1441 compatible RR types, such as the HTTPS RR. 1443 ACTION: create and include a reference to this registry. 1445 12.3.1. Procedure 1447 A registration MUST include the following fields: 1449 o Number: SvcParamKey wire format numeric identifier (range 0-65535) 1451 o Name: SvcParamKey presentation name 1453 o Meaning: a short description 1455 o Pointer to specification text 1457 SvcParamKey entries to be added to this namespace have different 1458 policies ([RFC5226], Section 4.1) based on their range: 1460 +-------------+-------------------------+ 1461 | Number | IANA Policy | 1462 +-------------+-------------------------+ 1463 | 0-255 | Standards Action | 1464 | | | 1465 | 256-32767 | Expert Review | 1466 | | | 1467 | 32768-65280 | First Come First Served | 1468 | | | 1469 | 65280-65534 | Private Use | 1470 | | | 1471 | 65535 | Standards Action | 1472 +-------------+-------------------------+ 1474 Apart from the initial contents, the SvcParamKey name MUST NOT start 1475 with "key". 1477 12.3.2. Initial contents 1479 The "Service Binding (SVCB) Parameter Registry" shall initially be 1480 populated with the registrations below: 1482 +-------------+-----------------+----------------------+------------+ 1483 | Number | Name | Meaning | Reference | 1484 +-------------+-----------------+----------------------+------------+ 1485 | 0 | mandatory | Mandatory keys in | (This | 1486 | | | this RR | document) | 1487 | | | | | 1488 | 1 | alpn | Additional supported | (This | 1489 | | | protocols | document) | 1490 | | | | | 1491 | 2 | no-default-alpn | No support for | (This | 1492 | | | default protocol | document) | 1493 | | | | | 1494 | 3 | port | Port for alternative | (This | 1495 | | | endpoint | document) | 1496 | | | | | 1497 | 4 | ipv4hint | IPv4 address hints | (This | 1498 | | | | document) | 1499 | | | | | 1500 | 5 | echconfig | Encrypted | (This | 1501 | | | ClientHello info | document) | 1502 | | | | | 1503 | 6 | ipv6hint | IPv6 address hints | (This | 1504 | | | | document) | 1505 | | | | | 1506 | 65280-65534 | keyNNNNN | Private Use | (This | 1507 | | | | document) | 1508 | | | | | 1509 | 65535 | key65535 | Reserved ("Invalid | (This | 1510 | | | key") | document) | 1511 +-------------+-----------------+----------------------+------------+ 1513 TODO: do we also want to reserve a range for greasing? 1515 12.4. Registry updates 1517 Per [RFC6895], please add the following entries to the data type 1518 range of the Resource Record (RR) TYPEs registry: 1520 +-------+------------------------------------------+----------------+ 1521 | TYPE | Meaning | Reference | 1522 +-------+------------------------------------------+----------------+ 1523 | SVCB | Service Location and Parameter Binding | (This | 1524 | | | document) | 1525 | | | | 1526 | HTTPS | HTTPS Service Location and Parameter | (This | 1527 | | Binding | document) | 1528 +-------+------------------------------------------+----------------+ 1529 Per [Attrleaf], please add the following entry to the DNS Underscore 1530 Global Scoped Entry Registry: 1532 +---------+------------+-----------------+-----------------+ 1533 | RR TYPE | _NODE NAME | Meaning | Reference | 1534 +---------+------------+-----------------+-----------------+ 1535 | HTTPS | _https | HTTPS SVCB info | (This document) | 1536 +---------+------------+-----------------+-----------------+ 1538 13. Acknowledgments and Related Proposals 1540 There have been a wide range of proposed solutions over the years to 1541 the "CNAME at the Zone Apex" challenge proposed. These include 1542 [I-D.bellis-dnsop-http-record], [I-D.ietf-dnsop-aname], and others. 1544 Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thomson, Lucas 1545 Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, David 1546 Benjamin, and others for their feedback and suggestions on this 1547 draft. 1549 14. References 1551 14.1. Normative References 1553 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1554 "Transport Layer Security (TLS) Application-Layer Protocol 1555 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1556 July 2014, . 1558 [Attrleaf] 1559 Crocker, D., "Scoped Interpretation of DNS Resource 1560 Records through "Underscored" Naming of Attribute Leaves", 1561 BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, 1562 . 1564 [base64] Josefsson, S., "The Base16, Base32, and Base64 Data 1565 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1566 . 1568 [DNAME] Rose, S. and W. Wijngaards, "DNAME Redirection in the 1569 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 1570 . 1572 [DoH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1573 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1574 . 1576 [DoT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1577 and P. Hoffman, "Specification for DNS over Transport 1578 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1579 2016, . 1581 [ECH] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 1582 Encrypted Client Hello", draft-ietf-tls-esni-07 (work in 1583 progress), June 2020. 1585 [HappyEyeballsV2] 1586 Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1587 Better Connectivity Using Concurrency", RFC 8305, 1588 DOI 10.17487/RFC8305, December 2017, 1589 . 1591 [HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1592 Transport Security (HSTS)", RFC 6797, 1593 DOI 10.17487/RFC6797, November 2012, 1594 . 1596 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 1597 (HTTP/3)", draft-ietf-quic-http-29 (work in progress), 1598 June 2020. 1600 [RFC1035] Mockapetris, P., "Domain names - implementation and 1601 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1602 November 1987, . 1604 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1605 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1606 DOI 10.17487/RFC1928, March 1996, 1607 . 1609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1610 Requirement Levels", BCP 14, RFC 2119, 1611 DOI 10.17487/RFC2119, March 1997, 1612 . 1614 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 1615 RFC 3225, DOI 10.17487/RFC3225, December 2001, 1616 . 1618 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 1619 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 1620 2003, . 1622 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1623 IANA Considerations Section in RFCs", RFC 5226, 1624 DOI 10.17487/RFC5226, May 2008, 1625 . 1627 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1628 Specifications: ABNF", STD 68, RFC 5234, 1629 DOI 10.17487/RFC5234, January 2008, 1630 . 1632 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1633 Address Text Representation", RFC 5952, 1634 DOI 10.17487/RFC5952, August 2010, 1635 . 1637 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1638 Extensions: Extension Definitions", RFC 6066, 1639 DOI 10.17487/RFC6066, January 2011, 1640 . 1642 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1643 Beijnum, "DNS64: DNS Extensions for Network Address 1644 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1645 DOI 10.17487/RFC6147, April 2011, 1646 . 1648 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1649 the IPv6 Prefix Used for IPv6 Address Synthesis", 1650 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1651 . 1653 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1654 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1655 DOI 10.17487/RFC7231, June 2014, 1656 . 1658 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 1659 and Registration Procedures for URI Schemes", BCP 35, 1660 RFC 7595, DOI 10.17487/RFC7595, June 2015, 1661 . 1663 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1664 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1665 May 2017, . 1667 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1668 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1669 . 1671 [WebSocket] 1672 Fette, I. and A. Melnikov, "The WebSocket Protocol", 1673 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1674 . 1676 14.2. Informative References 1678 [AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1679 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1680 April 2016, . 1682 [DNSTerm] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1683 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1684 January 2019, . 1686 [FETCH] "Fetch Living Standard", May 2020, 1687 . 1689 [I-D.bellis-dnsop-http-record] 1690 Bellis, R., "A DNS Resource Record for HTTP", draft- 1691 bellis-dnsop-http-record-00 (work in progress), November 1692 2018. 1694 [I-D.ietf-dnsop-aname] 1695 Finch, T., Hunt, E., Dijk, P., Eden, A., and W. Mekking, 1696 "Address-specific DNS aliases (ANAME)", draft-ietf-dnsop- 1697 aname-04 (work in progress), July 2019. 1699 [I-D.tapril-ns2] 1700 April, T., "Parameterized Nameserver Delegation with NS2 1701 and NS2T", draft-tapril-ns2-00 (work in progress), March 1702 2020. 1704 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1705 DOI 10.17487/RFC6454, December 2011, 1706 . 1708 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 1709 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 1710 April 2013, . 1712 [SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1713 specifying the location of services (DNS SRV)", RFC 2782, 1714 DOI 10.17487/RFC2782, February 2000, 1715 . 1717 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1718 Resource Identifier (URI): Generic Syntax", STD 66, 1719 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1720 . 1722 14.3. URIs 1724 [1] https://github.com/MikeBishop/dns-alt-svc 1726 Appendix A. Decoding text in zone files 1728 DNS zone files are capable of representing arbitrary octet sequences 1729 in basic ASCII text, using various delimiters and encodings. The 1730 algorithm for decoding these character-strings is defined in 1731 Section 5.1 of [RFC1035]. Here we summarize the allowed input to 1732 that algorithm, using ABNF: 1734 ; non-special is VCHAR minus DQUOTE, ";", "(", ")", and "\". 1735 non-special = %x21 / %x23-27 / %x2A-3A / %x3C-5B / %x5D-7E 1736 ; non-digit is VCHAR minus DIGIT 1737 non-digit = %x21-2F / %x3A-7E 1738 ; dec-octet is a number 0-255 as a three-digit decimal number. 1739 dec-octet = ( "0" / "1" ) 2DIGIT / 1740 "2" ( ( %x30-34 DIGIT ) / ( "5" %x30-35 ) ) 1741 escaped = "\" ( non-digit / dec-octet ) 1742 contiguous = 1*( non-special / escaped ) 1743 quoted = DQUOTE *( contiguous / ( ["\"] WSP ) ) DQUOTE 1744 char-string = contiguous / quoted 1746 The decoding algorithm allows "char-string" to represent any 1747 "*OCTET". In this document, this algorithm is referred to as 1748 "character-string decoding". The algorithm is the same as used by 1749 "" in RFC 1035, although the output length in this 1750 document is not limited to 255 octets. 1752 A.1. Decoding a value list 1754 In order to represent lists of values in zone files, this 1755 specification uses an extended version of character-string decoding 1756 that adds the use of "," as a delimiter after double-quote 1757 processing. When "," is not escaped (by a preceding "\" or as the 1758 escape sequence "\044"), it separates values in the output, which is 1759 a list of 1*OCTET. (For simplicity, empty values are not allowed.) 1760 We refer to this modified procedure as "value-list decoding". 1762 value-list = char-string 1763 list-value = 1*OCTET 1764 For example, consider these "char-string" SvcParamValues: 1766 "part1,part2\,part3" 1767 part1,part2\044part3 1769 Character-string decoding either of these inputs would produce a 1770 single "*OCTET" output: 1772 part1,part2,part3 1774 Value-list decoding either of these inputs would instead convert it 1775 to a list of two "list-value"s: 1777 part1 1778 part2,part3 1780 Appendix B. Comparison with alternatives 1782 The SVCB and HTTPS RR types closely resemble, and are inspired by, 1783 some existing record types and proposals. A complaint with all of 1784 the alternatives is that web clients have seemed unenthusiastic about 1785 implementing them. The hope here is that by providing an extensible 1786 solution that solves multiple problems we will overcome the inertia 1787 and have a path to achieve client implementation. 1789 B.1. Differences from the SRV RR type 1791 An SRV record [SRV] can perform a similar function to the SVCB 1792 record, informing a client to look in a different location for a 1793 service. However, there are several differences: 1795 o SRV records are typically mandatory, whereas clients will always 1796 continue to function correctly without making use of SVCB. 1798 o SRV records cannot instruct the client to switch or upgrade 1799 protocols, whereas SVCB can signal such an upgrade (e.g. to 1800 HTTP/2). 1802 o SRV records are not extensible, whereas SVCB and HTTPS RRs can be 1803 extended with new parameters. 1805 o SVCB records use 16 bit for SvcPriority for consistency with SRV 1806 and other RR types that also use 16 bit priorities. 1808 B.2. Differences from the proposed HTTP record 1810 Unlike [I-D.bellis-dnsop-http-record], this approach is extensible to 1811 cover Alt-Svc and Encrypted ClientHello use-cases. Like that 1812 proposal, this addresses the zone apex CNAME challenge. 1814 Like that proposal, it remains necessary to continue to include 1815 address records at the zone apex for legacy clients. 1817 B.3. Differences from the proposed ANAME record 1819 Unlike [I-D.ietf-dnsop-aname], this approach is extensible to cover 1820 Alt-Svc and ECH use-cases. This approach also does not require any 1821 changes or special handling on either authoritative or primary 1822 servers, beyond optionally returning in-bailiwick additional records. 1824 Like that proposal, this addresses the zone apex CNAME challenge for 1825 clients that implement this. 1827 However, with this SVCB proposal, it remains necessary to continue to 1828 include address records at the zone apex for legacy clients. If 1829 deployment of this standard is successful, the number of legacy 1830 clients will fall over time. As the number of legacy clients 1831 declines, the operational effort required to serve these users 1832 without the benefit of SVCB indirection should fall. Server 1833 operators can easily observe how much traffic reaches this legacy 1834 endpoint, and may remove the apex's address records if the observed 1835 legacy traffic has fallen to negligible levels. 1837 B.4. Comparison with separate RR types for AliasMode and ServiceMode 1839 Abstractly, functions of AliasMode and ServiceMode are independent, 1840 so it might be tempting to specify them as separate RR types. 1841 However, this would result in a serious performance impairment, 1842 because clients cannot rely on their recursive resolver to follow 1843 SVCB aliases (unlike CNAME). Thus, clients would have to issue 1844 queries for both RR types in parallel, potentially at each step of 1845 the alias chain. Recursive resolvers that implement the 1846 specification would, upon receipt of a ServiceMode query, emit both a 1847 ServiceMode and an AliasMode query to the authoritative. Thus, 1848 splitting the RR type would double, or in some cases triple, the load 1849 on clients and servers, and would not reduce implementation 1850 complexity. 1852 Appendix C. Change history 1854 o draft-ietf-dnsop-svcb-https-01 1856 * Added a "mandatory" SvcParamKey 1858 * Added the ability to indicate that a service does not exist 1860 * Adjusted resolution and ALPN algorithms 1862 * Major terminology revisions for "origin" and CamelCase names 1864 * Revised ABNF 1866 * Include allocated RR type numbers 1868 * Various corrections, explanations, and recommendations 1870 o draft-ietf-dnsop-svcb-https-00 1872 * Rename HTTPSSVC RR to HTTPS RR 1874 * Rename "an SVCB" to "a SVCB" 1876 * Removed "design considerations and open issues" section and 1877 some other "to be removed" text 1879 o draft-ietf-dnsop-svcb-httpssvc-03 1881 * Revised chain length limit requirements 1883 * Revised IANA registry rules for SvcParamKeys 1885 * Require HTTPS clients to implement SNI 1887 * Update terminology for Encrypted ClientHello 1889 * Clarifications: non-default ports, transport proxies, HSTS 1890 procedure, WebSocket behavior, wire format, IP hints, inner/ 1891 outer ClientHello with ECH 1893 * Various textual and ABNF corrections 1895 o draft-ietf-dnsop-svcb-httpssvc-02 1897 * All changes to Alt-Svc have been removed 1899 * Expanded and reorganized examples 1900 * Priority zero is now the definition of AliasForm 1902 * Repeated SvcParamKeys are no longer allowed 1904 * The "=" sign may be omitted in a key=value pair if the value is 1905 also empty 1907 * In the wire format, SvcParamKeys must be in sorted order 1909 * New text regarding how to handle resolution timeouts 1911 * Expanded description of recursive resolver behavior 1913 * Much more precise description of the intended ALPN behavior 1915 * Match the HSTS specification's language on HTTPS enforcement 1917 * Removed 'esniconfig=""' mechanism and simplified ESNI 1918 connection logic 1920 o draft-ietf-dnsop-svcb-httpssvc-01 1922 * Reduce the emphasis on conversion between HTTPSSVC and Alt-Svc 1924 * Make the "untrusted channel" concept more precise. 1926 * Make SvcFieldPriority = 0 the definition of AliasForm, instead 1927 of a requirement. 1929 o draft-ietf-dnsop-svcb-httpssvc-00 1931 * Document an optimization for optimistic pre-connection. (Chris 1932 Wood) 1934 * Relax IP hint handling requirements. (Eric Rescorla) 1936 o draft-nygren-dnsop-svcb-httpssvc-00 1938 * Generalize to an SVCB record, with special-case handling for 1939 Alt-Svc and HTTPS separated out to dedicated sections. 1941 * Split out a separate HTTPSSVC record for the HTTPS use-case. 1943 * Remove the explicit SvcRecordType=0/1 and instead make the 1944 AliasForm vs ServiceForm be implicit. This was based on 1945 feedback recommending against subtyping RR type. 1947 * Remove one optimization. 1949 o draft-nygren-httpbis-httpssvc-03 1951 * Change redirect type for HSTS-style behavior from 302 to 307 to 1952 reduce ambiguities. 1954 o draft-nygren-httpbis-httpssvc-02 1956 * Remove the redundant length fields from the wire format. 1958 * Define a SvcDomainName of "." for SvcRecordType=1 as being the 1959 HTTPSSVC RRNAME. 1961 * Replace "hq" with "h3". 1963 o draft-nygren-httpbis-httpssvc-01 1965 * Fixes of record name. Replace references to "HTTPSVC" with 1966 "HTTPSSVC". 1968 o draft-nygren-httpbis-httpssvc-00 1970 * Initial version 1972 Authors' Addresses 1974 Ben Schwartz 1975 Google 1977 Email: bemasc@google.com 1979 Mike Bishop 1980 Akamai Technologies 1982 Email: mbishop@evequefou.be 1984 Erik Nygren 1985 Akamai Technologies 1987 Email: erik+ietf@nygren.org