idnits 2.17.1 draft-ietf-dnsop-svcb-https-02.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 (November 2, 2020) is 1271 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 1855 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-08 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-32 ** 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: May 6, 2021 E. Nygren 6 Akamai Technologies 7 November 2, 2020 9 Service binding and parameter specification via the DNS (DNS SVCB and 10 HTTPS RRs) 11 draft-ietf-dnsop-svcb-https-02 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 May 6, 2021. 49 Copyright Notice 51 Copyright (c) 2020 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 . . . . . . . . . . 12 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" . . . . . . . . . . . . . . . . . . . . . . . 20 96 6.4. "ipv4hint" and "ipv6hint" . . . . . . . . . . . . . . . . 21 98 7. ServiceMode RR compatibility and mandatory keys . . . . . . . 22 99 8. Using SVCB with HTTPS and HTTP . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . 25 109 8.6. HTTP-based protocols . . . . . . . . . . . . . . . . . . 26 110 9. SVCB/HTTPS RR parameter for ECH configuration . . . . . . . . 26 111 9.1. Client behavior . . . . . . . . . . . . . . . . . . . . . 27 112 9.2. Deployment considerations . . . . . . . . . . . . . . . . 27 113 10. Zone Structures . . . . . . . . . . . . . . . . . . . . . . . 27 114 10.1. Structuring zones for flexibility . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . 28 119 10.3.3. Parameter binding . . . . . . . . . . . . . . . . . 29 120 10.3.4. Multi-CDN . . . . . . . . . . . . . . . . . . . . . 29 121 10.3.5. Non-HTTPS uses . . . . . . . . . . . . . . . . . . . 31 122 11. Interaction with other standards . . . . . . . . . . . . . . 32 123 12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 124 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 125 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 126 14.1. SVCB RRType . . . . . . . . . . . . . . . . . . . . . . 33 127 14.2. HTTPS RRType . . . . . . . . . . . . . . . . . . . . . . 33 128 14.3. New registry for Service Parameters . . . . . . . . . . 34 129 14.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . 34 130 14.3.2. Initial contents . . . . . . . . . . . . . . . . . . 34 131 14.4. Registry updates . . . . . . . . . . . . . . . . . . . . 35 132 15. Acknowledgments and Related Proposals . . . . . . . . . . . . 36 133 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 134 16.1. Normative References . . . . . . . . . . . . . . . . . . 36 135 16.2. Informative References . . . . . . . . . . . . . . . . . 39 136 16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 40 137 Appendix A. Decoding text in zone files . . . . . . . . . . . . 40 138 A.1. Decoding a value-list . . . . . . . . . . . . . . . . . . 40 139 Appendix B. Comparison with alternatives . . . . . . . . . . . . 41 140 B.1. Differences from the SRV RR type . . . . . . . . . . . . 41 141 B.2. Differences from the proposed HTTP record . . . . . . . . 41 142 B.3. Differences from the proposed ANAME record . . . . . . . 42 143 B.4. Comparison with separate RR types for AliasMode and 144 ServiceMode . . . . . . . . . . . . . . . . . . . . . . . 42 145 Appendix C. Change history . . . . . . . . . . . . . . . . . . . 42 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 148 1. Introduction 150 The SVCB ("Service Binding") and HTTPS RRs provide clients with 151 complete instructions for access to a service. This information 152 enables improved performance and privacy by avoiding transient 153 connections to a sub-optimal default server, negotiating a preferred 154 protocol, and providing relevant public keys. 156 For example, when clients need to make a connection to fetch 157 resources associated with an HTTPS URI, they currently resolve only A 158 and/or AAAA records for the origin hostname. This is adequate for 159 services that use basic HTTPS (fixed port, no QUIC, no [ECH]). Going 160 beyond basic HTTPS confers privacy, performance, and operational 161 advantages, but it requires the client to learn additional 162 information, and it is highly desirable to minimize the number of 163 round-trips and lookups required to learn this additional 164 information. 166 The SVCB and HTTPS RRs also help when the operator of a service 167 wishes to delegate operational control to one or more other domains, 168 e.g. delegating the origin "https://example.com" to a service 169 operator endpoint at "svc.example.net". While this case can 170 sometimes be handled by a CNAME, that does not cover all use-cases. 171 CNAME is also inadequate when the service operator needs to provide a 172 bound collection of consistent configuration parameters through the 173 DNS (such as network location, protocol, and keying information). 175 This document first describes the SVCB RR as a general-purpose 176 resource record that can be applied directly and efficiently to a 177 wide range of services (Section 2). The HTTPS RR is then defined as 178 a special case of SVCB that improves efficiency and convenience for 179 use with HTTPS (Section 8) by avoiding the need for an Attrleaf label 180 [Attrleaf] (Section 8.1). Other protocols with similar needs may 181 follow the pattern of HTTPS and assign their own SVCB-compatible RR 182 types. 184 All behaviors described as applying to the SVCB RR also apply to the 185 HTTPS RR unless explicitly stated otherwise. Section 8 describes 186 additional behaviors specific to the HTTPS RR. Apart from Section 8 187 and introductory examples, much of this document refers only to the 188 SVCB RR, but those references should be taken to apply to SVCB, 189 HTTPS, and any future SVCB-compatible RR types. 191 The SVCB RR has two modes: 1) "AliasMode" simply delegates 192 operational control for a resource; 2) "ServiceMode" binds together 193 configuration information for a service endpoint. ServiceMode 194 provides additional key=value parameters within each RDATA set. 196 1.1. Goals of the SVCB RR 198 The goal of the SVCB RR is to allow clients to resolve a single 199 additional DNS RR in a way that: 201 o Provides alternative endpoints that are authoritative for the 202 service, along with parameters associated with each of these 203 endpoints. 205 o Does not assume that all alternative endpoints have the same 206 parameters or capabilities, or are even operated by the same 207 entity. This is important as DNS does not provide any way to tie 208 together multiple RRs for the same name. For example, if 209 www.example.com is a CNAME alias that switches between one of 210 three CDNs or hosting environments, successive queries for that 211 name may return records that correspond to different environments. 213 o Enables CNAME-like functionality at a zone apex (such as 214 "example.com") for participating protocols, and generally enables 215 delegation of operational authority for an origin within the DNS 216 to an alternate name. 218 Additional goals specific to HTTPS RRs and the HTTPS use-case 219 include: 221 o Connect directly to HTTP3 (QUIC transport) alternative endpoints 222 [HTTP3] 224 o Obtain the Encrypted ClientHello [ECH] keys associated with an 225 alternative endpoint 227 o Support non-default TCP and UDP ports 229 o Enable SRV-like benefits (e.g. apex delegation, as mentioned 230 above) for HTTP(S), where SRV [SRV] has not been widely adopted 232 o Provide an HSTS-like indication [HSTS] signaling that the HTTPS 233 scheme should be used instead of HTTP for this request (see 234 Section 8.5). 236 1.2. Overview of the SVCB RR 238 This subsection briefly describes the SVCB RR in a non-normative 239 manner. (As mentioned above, this all applies equally to the HTTPS 240 RR which shares the same encoding, format, and high-level semantics.) 241 The SVCB RR has two modes: AliasMode, which aliases a name to another 242 name, and ServiceMode, which provides connection information bound to 243 a service endpoint domain. Placing both forms in a single RR type 244 allows clients to fetch the relevant information with a single query. 246 The SVCB RR has two mandatory fields and one optional. The fields 247 are: 249 1. SvcPriority: The priority of this record (relative to others, 250 with lower values preferred). A value of 0 indicates AliasMode. 251 (Described in Section 2.4.1.) 253 2. TargetName: The domain name of either the alias target (for 254 AliasMode) or the alternative endpoint (for ServiceMode). 256 3. SvcParams (optional): A list of key=value pairs describing the 257 alternative endpoint at TargetName (only used in ServiceMode and 258 otherwise ignored). Described in Section 2.1. 260 Cooperating DNS recursive resolvers will perform subsequent record 261 resolution (for SVCB, A, and AAAA records) and return them in the 262 Additional Section of the response. Clients either use responses 263 included in the additional section returned by the recursive resolver 264 or perform necessary SVCB, A, and AAAA record resolutions. DNS 265 authoritative servers can attach in-bailiwick SVCB, A, AAAA, and 266 CNAME records in the Additional Section to responses for a SVCB 267 query. 269 In ServiceMode, the SvcParams of the SVCB RR provide an extensible 270 data model for describing alternative endpoints that are 271 authoritative for the origin, along with parameters associated with 272 each of these alternative endpoints. 274 For the HTTPS use-case, the HTTPS RR enables many of the benefits of 275 Alt-Svc [AltSvc] without waiting for a full HTTP connection 276 initiation (multiple roundtrips) before learning of the preferred 277 alternative, and without necessarily revealing the user's intended 278 destination to all entities along the network path. 280 1.3. Parameter for Encrypted ClientHello 282 This document also defines a parameter for Encrypted ClientHello 283 [ECH] keys. See Section 9. 285 1.4. Terminology 287 Our terminology is based on the common case where the SVCB record is 288 used to access a resource identified by a URI whose "authority" field 289 contains a DNS hostname as the "host". 291 o The "service" is the information source identified by the 292 "authority" and "scheme" of the URI, capable of providing access 293 to the resource. For HTTPS URIs, the "service" corresponds to an 294 HTTPS "origin" [RFC6454]. 296 o The "service name" is the "host" portion of the authority. 298 o The "authority endpoint" is the authority's hostname and a port 299 number implied by the scheme or specified in the URI. 301 o An "alternative endpoint" is a hostname, port number, and other 302 associated instructions to the client on how to reach an instance 303 of service. 305 Additional DNS terminology intends to be consistent with [DNSTerm]. 307 SVCB is a contraction of "service binding". The SVCB RR, HTTPS RR, 308 and future RR types that share SVCB's format and registry are 309 collectively known as SVCB-compatible RR types. 311 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 312 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 313 "OPTIONAL" in this document are to be interpreted as described in BCP 314 14 [RFC2119] [RFC8174] when, and only when, they appear in all 315 capitals, as shown here. 317 2. The SVCB record type 319 The SVCB DNS resource record (RR) type (RR type 64) is used to locate 320 alternative endpoints for a service. 322 The algorithm for resolving SVCB records and associated address 323 records is specified in Section 3. 325 Other SVCB-compatible resource record types can also be defined as- 326 needed. In particular, the HTTPS RR (RR type 65) provides special 327 handling for the case of "https" origins as described in Section 8. 329 SVCB RRs are extensible by a list of SvcParams, which are pairs 330 consisting of a SvcParamKey and a SvcParamValue. Each SvcParamKey 331 has a presentation name and a registered number. Values are in a 332 format specific to the SvcParamKey. Their definition should specify 333 both their presentation format and wire encoding (e.g., domain names, 334 binary data, or numeric values). The initial SvcParamKeys and 335 formats are defined in Section 6. 337 2.1. Zone file presentation format 339 The presentation format of the record is: 341 Name TTL IN SVCB SvcPriority TargetName SvcParams 343 The SVCB record is defined specifically within the Internet ("IN") 344 Class ([RFC1035]). 346 SvcPriority is a number in the range 0-65535, TargetName is a domain 347 name, and the SvcParams are a whitespace-separated list, with each 348 SvcParam consisting of a SvcParamKey=SvcParamValue pair or a 349 standalone SvcParamKey. SvcParamKeys are subject to IANA control 350 (Section 14.3). 352 Each SvcParamKey SHALL appear at most once in the SvcParams. In 353 presentation format, SvcParamKeys are lower-case alphanumeric 354 strings. Key names should contain 1-63 characters from the ranges 355 "a"-"z", "0"-"9", and "-". In ABNF [RFC5234], 357 alpha-lc = %x61-7A ; a-z 358 SvcParamKey = 1*63(alpha-lc / DIGIT / "-") 359 SvcParam = SvcParamKey ["=" SvcParamValue] 360 SvcParamValue = char-string 361 value = *OCTET 363 Unless otherwise specified, the SvcParamValue is parsed using the 364 character-string decoding algorithm (Appendix A), producing a 365 "value". The "value" is then validated and converted into wire- 366 format in a manner specific to each key. 368 When the "=" is omitted, the "value" is interpreted as empty. 370 Unrecognized keys are represented in presentation format as 371 "keyNNNNN" where NNNNN is the numeric value of the key type without 372 leading zeros. A SvcParam in this form SHALL be parsed as specified 373 above, and the decoded "value" SHALL be used as its wire format 374 encoding. 376 For some SvcParamKeys, the SvcParamValue corresponds to a list or set 377 of items. Presentation formats for such keys SHOULD make use of the 378 decoding algorithm in Appendix A.1, producing a "value-list". 380 SvcParams in presentation format MAY appear in any order, but keys 381 MUST NOT be repeated. 383 2.2. RDATA wire format 385 The RDATA for the SVCB RR consists of: 387 o a 2 octet field for SvcPriority as an integer in network byte 388 order. 390 o the uncompressed, fully-qualified TargetName, represented as a 391 sequence of length-prefixed labels as in Section 3.1 of [RFC1035]. 393 o the SvcParams, consuming the remainder of the record (so smaller 394 than 65535 octets and constrained by the RDATA and DNS message 395 sizes). 397 When the list of SvcParams is non-empty (ServiceMode), it contains a 398 series of SvcParamKey=SvcParamValue pairs, represented as: 400 o a 2 octet field containing the SvcParamKey as an integer in 401 network byte order. (See Section 14.3.2 for the defined values.) 403 o a 2 octet field containing the length of the SvcParamValue as an 404 integer between 0 and 65535 in network byte order (but constrained 405 by the RDATA and DNS message sizes). 407 o an octet string of this length whose contents are in a format 408 determined by the SvcParamKey. 410 SvcParamKeys SHALL appear in increasing numeric order. 412 Clients MUST consider an RR malformed if: 414 o the end of the RDATA occurs within a SvcParam. 416 o SvcParamKeys are not in strictly increasing numeric order. 418 o the SvcParamValue for an SvcParamKey does not have the expected 419 format. 421 Note that the second condition implies that there are no duplicate 422 SvcParamKeys. 424 If any RRs are malformed, the client MUST reject the entire RRSet and 425 fall back to non-SVCB connection establishment. 427 2.3. SVCB query names 429 When querying the SVCB RR, a service is translated into a QNAME by 430 prepending the service name with a label indicating the scheme, 431 prefixed with an underscore, resulting in a domain name like 432 "_examplescheme.api.example.com.". This follows the Attrleaf naming 433 pattern [Attrleaf], so the scheme MUST be registered appropriately 434 with IANA (see Section 11). 436 Protocol mapping documents MAY specify additional underscore-prefixed 437 labels to be prepended. For schemes that specify a port 438 (Section 3.2.3 of [URI]), one reasonable possibility is to prepend 439 the indicated port number (or the default if no port number is 440 specified). We term this behavior "Port Prefix Naming", and use it 441 in the examples throughout this document. 443 See Section 8.1 for the HTTPS RR behavior. 445 When a prior CNAME or SVCB record has aliased to a SVCB record, each 446 RR shall be returned under its own owner name. 448 Note that none of these forms alter the origin or authority for 449 validation purposes. For example, TLS clients MUST continue to 450 validate TLS certificates for the original service name. 452 As an example, the owner of example.com could publish this record: 454 _8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net. 456 to indicate that "foo://api.example.com:8443" is aliased to 457 "svc4.example.net". The owner of example.net, in turn, could publish 458 this record: 460 svc4.example.net. 7200 IN SVCB 3 svc4.example.net. ( 461 alpn="bar" port="8004" echconfig="..." ) 463 to indicate that these services are served on port number 8004, which 464 supports the protocol "bar" and its associated transport in addition 465 to the default transport protocol for "foo://". 467 (Parentheses are used to ignore a line break ([RFC1035] 468 Section 5.1).) 470 2.4. Interpretation 471 2.4.1. SvcPriority 473 When SvcPriority is 0 the SVCB record is in AliasMode 474 (Section 2.4.2). Otherwise, it is in ServiceMode (Section 2.4.3). 476 Within a SVCB RRSet, all RRs SHOULD have the same Mode. If an RRSet 477 contains a record in AliasMode, the recipient MUST ignore any 478 ServiceMode records in the set. 480 RRSets are explicitly unordered collections, so the SvcPriority field 481 is used to impose an ordering on SVCB RRs. SVCB RRs with a smaller 482 SvcPriority value SHOULD be given preference over RRs with a larger 483 SvcPriority value. 485 When receiving an RRSet containing multiple SVCB records with the 486 same SvcPriority value, clients SHOULD apply a random shuffle within 487 a priority level to the records before using them, to ensure uniform 488 load-balancing. 490 2.4.2. AliasMode 492 In AliasMode, the SVCB record aliases a service to a TargetName. 493 SVCB RRSets SHOULD only have a single resource record in AliasMode. 494 If multiple are present, clients or recursive resolvers SHOULD pick 495 one at random. 497 The primary purpose of AliasMode is to allow aliasing at the zone 498 apex, where CNAME is not allowed. In AliasMode, the TargetName will 499 be the name of a domain that resolves to SVCB (or other SVCB- 500 compatible record such as HTTPS), AAAA, and/or A records. The 501 TargetName SHOULD NOT be equal to the owner name, as this would 502 result in a loop. 504 In AliasMode, records SHOULD NOT include any SvcParams, and 505 recipients MUST ignore any SvcParams that are present. 507 For example, the operator of foo://example.com:8080 could point 508 requests to a service operating at foosvc.example.net by publishing: 510 _8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net. 512 Using AliasMode maintains a separation of concerns: the owner of 513 foosvc.example.net can add or remove ServiceMode SVCB records without 514 requiring a corresponding change to example.com. Note that if 515 foosvc.example.net promises to always publish a SVCB record, this 516 AliasMode record can be replaced by a CNAME, which would likely 517 improve performance. 519 AliasMode is especially useful for SVCB-compatible RR types that do 520 not require an underscore prefix, such as the HTTPS RR type. For 521 example, the operator of https://example.com could point requests to 522 a server at svc.example.net by publishing this record at the zone 523 apex: 525 example.com. 3600 IN HTTPS 0 svc.example.net. 527 Note that the SVCB record's owner name MAY be the canonical name of a 528 CNAME record, and the TargetName MAY be the owner of a CNAME record. 529 Clients and recursive resolvers MUST follow CNAMEs as normal. 531 To avoid unbounded alias chains, clients and recursive resolvers MUST 532 impose a limit on the total number of SVCB aliases they will follow 533 for each resolution request. This limit MUST NOT be zero, i.e. 534 implementations MUST be able to follow at least one AliasMode record. 535 The exact value of this limit is left to implementations. 537 For compatibility and performance, zone owners SHOULD NOT configure 538 their zones to require following multiple AliasMode records. 540 As legacy clients will not know to use this record, service operators 541 will likely need to retain fallback AAAA and A records alongside this 542 SVCB record, although in a common case the target of the SVCB record 543 might offer better performance, and therefore would be preferable for 544 clients implementing this specification to use. 546 AliasMode records only apply to queries for the specific RR type. 547 For example, a SVCB record cannot alias to an HTTPS record, nor vice- 548 versa. 550 2.4.3. ServiceMode 552 In ServiceMode, the TargetName and SvcParams within each resource 553 record associate an alternative endpoint for the service with its 554 connection parameters. 556 Each protocol scheme that uses SVCB MUST define a protocol mapping 557 that explains how SvcParams are applied for connections of that 558 scheme. Unless specified otherwise by the protocol mapping, clients 559 MUST ignore any SvcParam that they do not recognize. 561 2.5. Special handling of "." in TargetName 563 If TargetName has the value "." (represented in the wire format as a 564 zero-length label), special rules apply. 566 2.5.1. AliasMode 568 For AliasMode SVCB RRs, a TargetName of "." indicates that the 569 service is not available or does not exist. This indication is 570 advisory: clients encountering this indication MAY ignore it and 571 attempt to connect without the use of SVCB. 573 2.5.2. ServiceMode 575 For ServiceMode SVCB RRs, if TargetName has the value ".", then the 576 owner name of this record MUST be used as the effective TargetName. 578 For example, in the following example "svc2.example.net" is the 579 effective TargetName: 581 example.com. 7200 IN HTTPS 0 svc.example.net. 582 svc.example.net. 7200 IN CNAME svc2.example.net. 583 svc2.example.net. 7200 IN HTTPS 1 . port=8002 echconfig="..." 584 svc2.example.net. 300 IN A 192.0.2.2 585 svc2.example.net. 300 IN AAAA 2001:db8::2 587 3. Client behavior 589 A SVCB-aware client selects an endpoint for a service using the 590 following procedure: 592 1. Let $ADDR_QNAME be the service name. Let $SVCB_QNAME be the 593 service name plus appropriate prefixes for the scheme (see 594 Section 2.3). 596 2. In parallel, issue AAAA/A queries for $ADDR_QNAME and a SVCB 597 query for $SVCB_QNAME. The answers for these may or may not 598 include CNAME pointers before reaching one or more of these 599 records. 601 3. If an AliasMode SVCB record is returned for $SVCB_QNAME, clients 602 MUST set $ADDR_QNAME and $SVCB_QNAME to its TargetName (without 603 additional prefixes) and loop back to step 2, subject to chain 604 length limits and loop detection heuristics (see Section 3.1). 606 4. If one or more "compatible" (Section 7) ServiceMode records are 607 returned for $SVCB_QNAME, clients SHOULD select the highest- 608 priority compatible record. This record's TargetName and 609 SvcParams represent the preferred endpoint. If connection to 610 this endpoint fails, the client SHOULD try to connect using 611 values from the next-highest-priority compatible record, etc. If 612 all attempts fail, clients SHOULD go to step 5 (except as noted 613 in Section 9.1). 615 5. At this point there are no usable ServiceMode records, because 617 * there were no SVCB records found for $SVCB_QNAME, OR 619 * all records found were incompatible with this client, OR 621 * all connection attempts using ServiceMode records failed. 623 Accordingly, clients SHALL connect to the endpoint consisting of 624 $ADDR_QNAME, the authority endpoint's port number, and no 625 SvcParams. 627 If all of the above connection attempts fail, clients MAY connect to 628 the authority endpoint (except as noted in Section 3.1 and 629 Section 9.1). 631 This procedure does not rely on any recursive or authoritative DNS 632 server to comply with this specification or have any awareness of 633 SVCB. 635 When selecting between AAAA and A records to use, clients may use an 636 approach such as Happy Eyeballs [HappyEyeballsV2]. 638 Some important optimizations are discussed in Section 5 to avoid 639 additional latency in comparison to ordinary AAAA/A lookups. 641 3.1. Handling resolution failures 643 If a SVCB query results in a SERVFAIL error, transport error, or 644 timeout, and DNS exchanges between the client and the recursive 645 resolver are cryptographically protected (e.g. using TLS [DoT] or 646 HTTPS [DoH]), the client SHOULD NOT fall back to $ADDR_QNAME (step 5 647 above) or the authority endpoint. Otherwise, an active attacker 648 could mount a downgrade attack by denying the user access to the 649 SvcParams. 651 A SERVFAIL error can occur if the domain is DNSSEC-signed, the 652 recursive resolver is DNSSEC-validating, and the attacker is between 653 the recursive resolver and the authoritative DNS server. A transport 654 error or timeout can occur if an active attacker between the client 655 and the recursive resolver is selectively dropping SVCB queries or 656 responses, based on their size or other observable patterns. 658 Similarly, if the client enforces DNSSEC validation on A/AAAA 659 responses, it SHOULD terminate the connection if a SVCB response 660 fails to validate. 662 If the client is unable to complete SVCB resolution due to its chain 663 length limit, the client SHOULD fall back to the authority endpoint, 664 as if the origin's SVCB record did not exist. 666 3.2. Clients using a Proxy 668 Clients using a domain-oriented transport proxy like HTTP CONNECT 669 ([RFC7231] Section 4.3.6) or SOCKS5 ([RFC1928]) have the option to 670 use named destinations, in which case the client does not perform any 671 A or AAAA queries for destination domains. If the client is using 672 named destinations with a proxy that does not provide SVCB query 673 capability (e.g. through an affiliated DNS resolver), the client 674 would have to perform SVCB queries though a separate resolver. This 675 might disclose the client's destinations to an additional party, 676 creating privacy concerns. If these concerns apply, the client 677 SHOULD disable SVCB resolution. 679 If the client does use SVCB and named destinations, the client SHOULD 680 follow the standard SVCB resolution process, selecting the smallest- 681 SvcPriority option that is compatible with the client and the proxy. 682 The client SHOULD provide the final TargetName and port to the proxy, 683 which will perform any required A and AAAA lookups. 685 Providing the proxy with the final TargetName has several benefits: 687 o It allows the client to use the SvcParams, if present, which is 688 only usable with a specific TargetName. The SvcParams may include 689 information that enhances performance (e.g. alpn) and privacy 690 (e.g. echconfig). 692 o It allows the service to delegate the apex domain. 694 o It allows the proxy to select between IPv4 and IPv6 addresses for 695 the server according to its configuration, and receive addresses 696 based on its network geolocation. 698 4. DNS Server Behavior 700 4.1. Authoritative servers 702 When replying to a SVCB query, authoritative DNS servers SHOULD 703 return A, AAAA, and SVCB records in the Additional Section for any 704 in-bailiwick TargetNames. If the zone is signed, the server SHOULD 705 also include positive or negative DNSSEC responses for these records 706 in the Additional section. 708 4.2. Recursive resolvers 710 Recursive resolvers that are aware of SVCB SHOULD help the client to 711 execute the procedure in Section 3 with minimum overall latency, by 712 incorporating additional useful information into the response. For 713 the initial SVCB record query, this is just the normal response 714 construction process (i.e. unknown RR type resolution under 715 [RFC3597]). For followup resolutions performed during this 716 procedure, we define incorporation as adding all useful RRs from the 717 response to the Additional section without altering the response 718 code. 720 Upon receiving a SVCB query, recursive resolvers SHOULD start with 721 the standard resolution procedure, and then follow this procedure to 722 construct the full response to the stub resolver: 724 1. Incorporate the results of SVCB resolution. If the chain length 725 limit has been reached, terminate successfully (i.e. a NOERROR 726 response). 728 2. If any of the resolved SVCB records are in AliasMode, choose one 729 of them at random, and resolve SVCB, A, and AAAA records for its 730 TargetName. 732 * If any SVCB records are resolved, go to step 1. 734 * Otherwise, incorporate the results of A and AAAA resolution, 735 and terminate. 737 3. All the resolved SVCB records are in ServiceMode. Resolve A and 738 AAAA queries for each TargetName (or for the owner name if 739 TargetName is "."), incorporate all the results, and terminate. 741 In this procedure, "resolve" means the resolver's ordinary recursive 742 resolution procedure, as if processing a query for that RRSet. This 743 includes following any aliases that the resolver would ordinarily 744 follow (e.g. CNAME, DNAME [DNAME]). 746 See Section 2.4.2 for additional safeguards for recursive resolvers 747 to implement to mitigate loops. 749 See Section 5.2 for possible optimizations of this procedure. 751 4.3. General requirements 753 Recursive resolvers SHOULD treat the SvcParams portion of the SVCB RR 754 as opaque and SHOULD NOT try to alter their behavior based on its 755 contents. 757 When responding to a query that includes the DNSSEC OK bit 758 ([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers 759 MUST accompany each RRSet in the Additional section with the same 760 DNSSEC-related records that they would send when providing that RRSet 761 as an Answer (e.g. RRSIG, NSEC, NSEC3). 763 5. Performance optimizations 765 For optimal performance (i.e. minimum connection setup time), clients 766 SHOULD issue address (AAAA and/or A) and SVCB queries simultaneously, 767 and SHOULD implement a client-side DNS cache. Responses in the 768 Additional section of a SVCB response SHOULD be placed in cache 769 before performing any followup queries. With these optimizations in 770 place, and conforming DNS servers, using SVCB does not add network 771 latency to connection setup. 773 5.1. Optimistic pre-connection and connection reuse 775 If an address response arrives before the corresponding SVCB 776 response, the client MAY initiate a connection as if the SVCB query 777 returned NODATA, but MUST NOT transmit any information that could be 778 altered by the SVCB response until it arrives. For example, a TLS 779 ClientHello can be altered by the "echconfig" value of a SVCB 780 response (Section 6.3). Clients implementing this optimization 781 SHOULD wait for 50 milliseconds before starting optimistic pre- 782 connection, as per the guidance in [HappyEyeballsV2]. 784 An SVCB record is consistent with a connection if the client would 785 attempt an equivalent connection when making use of that record. If 786 a SVCB record is consistent with an active or in-progress connection 787 C, the client MAY prefer that record and use C as its connection. 788 For example, suppose the client receives this SVCB RRSet for a 789 protocol that uses TLS over TCP: 791 _1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. ( 792 echconfig="111..." ipv6hint=2001:db8::1 port=1234 ) 793 SVCB 2 svc2.example.net. ( 794 echconfig="222..." ipv6hint=2001:db8::2 port=1234 ) 796 If the client has an in-progress TCP connection to 797 "[2001:db8::2]:1234", it MAY proceed with TLS on that connection 798 using "echconfig="222..."", even though the other record in the RRSet 799 has higher priority. 801 If none of the SVCB records are consistent with any active or in- 802 progress connection, clients must proceed as described in Step 3 of 803 the procedure in Section 3. 805 5.2. Generating and using incomplete responses 807 When following the procedure in Section 4.2, recursive resolvers MAY 808 terminate the procedure early and produce a reply that omits some of 809 the associated RRSets. This is REQUIRED when the chain length limit 810 is reached (Section 4.2 step 1), but might also be appropriate when 811 the maximum response size is reached, or when responding before fully 812 chasing dependencies would improve performance. When omitting 813 certain RRSets, recursive resolvers SHOULD prioritize information for 814 smaller-SvcPriority records. 816 As discussed in Section 3, clients MUST be able to fetch additional 817 information that is required to use a SVCB record, if it is not 818 included in the initial response. As a performance optimization, if 819 some of the SVCB records in the response can be used without 820 requiring additional DNS queries, the client MAY prefer those 821 records, regardless of their priorities. 823 6. Initial SvcParamKeys 825 A few initial SvcParamKeys are defined here. These keys are useful 826 for HTTPS, and most are applicable to other protocols as well. 828 6.1. "alpn" and "no-default-alpn" 830 The "alpn" and "no-default-alpn" SvcParamKeys together indicate the 831 set of Application Layer Protocol Negotiation (ALPN) protocol 832 identifiers [ALPN] and associated transport protocols supported by 833 this service endpoint. 835 As with Alt-Svc [AltSvc], the ALPN protocol identifier is used to 836 identify the application protocol and associated suite of protocols 837 supported by the endpoint (the "protocol suite"). Clients filter the 838 set of ALPN identifiers to match the protocol suites they support, 839 and this informs the underlying transport protocol used (such as 840 QUIC-over-UDP or TLS-over-TCP). 842 ALPNs are identified by their registered "Identification Sequence" 843 ("alpn-id"), which is a sequence of 1-255 octets. 845 alpn-id = 1*255OCTET 847 "alpn" is a multi-valued SvcParamKey. To construct its value-list, 848 apply the value-list decoding algorithm (Appendix A.1) to the 849 SvcParamValue. Each decoded value in the "alpn" value-list SHALL be 850 an "alpn-id". The value-list MUST NOT be empty. 852 The wire format value for "alpn" consists of at least one "alpn-id" 853 prefixed by its length as a single octet, and these length-value 854 pairs are concatenated to form the SvcParamValue. These pairs MUST 855 exactly fill the SvcParamValue; otherwise, the SvcParamValue is 856 malformed. 858 For "no-default-alpn", the presentation and wire format values MUST 859 be empty. 861 Each scheme that uses this SvcParamKey defines a "default set" of 862 supported ALPNs, which SHOULD NOT be empty. To determine the set of 863 protocol suites supported by an endpoint (the "SVCB ALPN set"), the 864 client adds the default set to the list of "alpn-id"s unless the "no- 865 default-alpn" SvcParamKey is present. The presence of an ALPN 866 protocol in the SVCB ALPN set indicates that this service endpoint, 867 described by TargetName and the other parameters (e.g. "port") offers 868 service with the protocol suite associated with this ALPN protocol. 870 ALPN protocol names that do not uniquely identify a protocol suite 871 (e.g. an Identification Sequence that can be used with both TLS and 872 DTLS) are not compatible with this SvcParamKey and MUST NOT be 873 included in the SVCB ALPN set. 875 To establish a connection to the endpoint, clients MUST 877 1. Let SVCB-ALPN-Intersection be the set of protocols in the SVCB 878 ALPN set that the client supports. 880 2. Let Intersection-Transports be the set of transports (e.g. TLS, 881 DTLS, QUIC) implied by the protocols in SVCB-ALPN-Intersection. 883 3. For each transport in Intersection-Transports, construct a 884 ProtocolNameList containing the Identification Sequences of all 885 the client's supported ALPN protocols for that transport, without 886 regard to the SVCB ALPN set. 888 For example, if the SVCB ALPN set is ["http/1.1", "h3"], and the 889 client supports HTTP/1.1, HTTP/2, and HTTP/3, the client could 890 attempt to connect using TLS over TCP with a ProtocolNameList of 891 ["http/1.1", "h2"], and could also attempt a connection using QUIC, 892 with a ProtocolNameList of ["h3"]. 894 Once the client has constructed a ClientHello, protocol negotiation 895 in that handshake proceeds as specified in [ALPN], without regard to 896 the SVCB ALPN set. 898 With this procedure in place, an attacker who can modify DNS and 899 network traffic can prevent a successful transport connection, but 900 cannot otherwise interfere with ALPN protocol selection. This 901 procedure also ensures that each ProtocolNameList includes at least 902 one protocol from the SVCB ALPN set. 904 Clients SHOULD NOT attempt connection to a service endpoint whose 905 SVCB ALPN set does not contain any supported protocols. To ensure 906 consistency of behavior, clients MAY reject the entire SVCB RRSet and 907 fall back to basic connection establishment if all of the RRs 908 indicate "no-default-alpn", even if connection could have succeeded 909 using a non-default alpn. 911 For compatibility with clients that require default transports, zone 912 operators SHOULD ensure that at least one RR in each RRSet supports 913 the default transports. 915 6.2. "port" 917 The "port" SvcParamKey defines the TCP or UDP port that should be 918 used to reach this alternative endpoint. If this key is not present, 919 clients SHALL use the authority endpoint's port number. 921 The presentation "value" of the SvcParamValue is a single decimal 922 integer between 0 and 65535 in ASCII. Any other "value" (e.g. an 923 empty value) is a syntax error. To enable simpler parsing, this 924 SvcParam MUST NOT contain escape sequences. 926 The wire format of the SvcParamValue is the corresponding 2 octet 927 numeric value in network byte order. 929 If a port-restricting firewall is in place between some client and 930 the service endpoint, changing the port number might cause that 931 client to lose access to the service, so operators should exercise 932 caution when using this SvcParamKey to specify a non-default port. 934 6.3. "echconfig" 936 The SvcParamKey to enable Encrypted ClientHello (ECH) is "echconfig". 937 Its value is defined in Section 9. It is applicable to most TLS- 938 based protocols. 940 When publishing a record containing an "echconfig" parameter, the 941 publisher MUST ensure that all IP addresses of TargetName correspond 942 to servers that have access to the corresponding private key or are 943 authoritative for the public name. (See Section 7.2.2 of [ECH] for 944 more details about the public name.) This yields an anonymity set of 945 cardinality equal to the number of ECH-enabled server domains 946 supported by a given client-facing server. Thus, even with an 947 encrypted ClientHello, an attacker who can enumerate the set of ECH- 948 enabled domains supported by a client-facing server can guess the 949 correct SNI with probability at least 1/K, where K is the size of 950 this ECH-enabled server anonymity set. This probability may be 951 increased via traffic analysis or other mechanisms. 953 6.4. "ipv4hint" and "ipv6hint" 955 The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients 956 MAY use to reach the service. If A and AAAA records for TargetName 957 are locally available, the client SHOULD ignore these hints. 958 Otherwise, clients SHOULD perform A and/or AAAA queries for 959 TargetName as in Section 3, and clients SHOULD use the IP address in 960 those responses for future connections. Clients MAY opt to terminate 961 any connections using the addresses in hints and instead switch to 962 the addresses in response to the TargetName query. Failure to use A 963 and/or AAAA response addresses could negatively impact load balancing 964 or other geo-aware features and thereby degrade client performance. 966 To construct the value-list, apply the value-list decoding algorithm 967 (Appendix A.1) to the SvcParamValue. Each decoded value in the 968 value-list SHALL be an IP address of the appropriate family in 969 standard textual format [RFC5952]. To enable simpler parsing, this 970 SvcParamValue MUST NOT contain escape sequences. 972 The wire format for each parameter is a sequence of IP addresses in 973 network byte order. Like an A or AAAA RRSet, the list of addresses 974 represents an unordered collection, and clients SHOULD pick addresses 975 to use in a random order. An empty list of addresses is invalid. 977 When selecting between IPv4 and IPv6 addresses to use, clients may 978 use an approach such as Happy Eyeballs [HappyEyeballsV2]. When only 979 "ipv4hint" is present, IPv6-only clients may synthesize IPv6 980 addresses as specified in [RFC7050] or ignore the "ipv4hint" key and 981 wait for AAAA resolution (Section 3). Recursive resolvers MUST NOT 982 perform DNS64 ([RFC6147]) on parameters within a SVCB record. For 983 best performance, server operators SHOULD include an "ipv6hint" 984 parameter whenever they include an "ipv4hint" parameter. 986 These parameters are intended to minimize additional connection 987 latency when a recursive resolver is not compliant with the 988 requirements in Section 4, and SHOULD NOT be included if most clients 989 are using compliant recursive resolvers. When TargetName is the 990 origin hostname or the owner name (which can be written as "."), 991 server operators SHOULD NOT include these hints, because they are 992 unlikely to convey any performance benefit. 994 7. ServiceMode RR compatibility and mandatory keys 996 In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the 997 RR will not function correctly for clients that ignore this 998 SvcParamKey. Each SVCB protocol mapping SHOULD specify a set of keys 999 that are "automatically mandatory", i.e. mandatory if they are 1000 present in an RR. The SvcParamKey "mandatory" is used to indicate 1001 any mandatory keys for this RR, in addition to any automatically 1002 mandatory keys that are present. 1004 A ServiceMode RR is considered "compatible" with a client if the 1005 client recognizes all the mandatory keys, and their values indicate 1006 that successful connection establishment is possible. If the SVCB 1007 RRSet contains no compatible RRs, the client will generally act as if 1008 the RRSet is empty. 1010 In presentation format, "mandatory" contains a list of one or more 1011 valid SvcParamKeys, either by their registered name or in the 1012 unknown-key format (Section 2.1). Keys MAY appear in any order, but 1013 MUST NOT appear more than once. Any listed keys MUST also appear in 1014 the SvcParams. 1016 To construct the value-list, apply the value-list decoding algorithm 1017 (Appendix A.1) to the SvcParamValue. To enable simpler parsing, this 1018 SvcParamValue MUST NOT contain escape sequences. 1020 For example, the following is a valid list of SvcParams: 1022 echconfig=... key65333=ex1 key65444=ex2 mandatory=key65444,echconfig 1024 In wire format, the keys are represented by their numeric values in 1025 network byte order, concatenated in ascending order. 1027 This SvcParamKey is always automatically mandatory, and MUST NOT 1028 appear in its own value-list. Other automatically mandatory keys 1029 SHOULD NOT appear in the list either. (Including them wastes space 1030 and otherwise has no effect.) 1032 8. Using SVCB with HTTPS and HTTP 1034 Use of any protocol with SVCB requires a protocol-specific mapping 1035 specification. This section specifies the mapping for HTTPS and 1036 HTTP. 1038 To enable special handling for the HTTPS and HTTP use-cases, the 1039 HTTPS RR type is defined as a SVCB-compatible RR type, specific to 1040 the https and http schemes. Clients MUST NOT perform SVCB queries or 1041 accept SVCB responses for "https" or "http" schemes. 1043 The HTTPS RR wire format and presentation format are identical to 1044 SVCB, and both share the SvcParamKey registry. SVCB semantics apply 1045 equally to HTTPS RRs unless specified otherwise. The presentation 1046 format of the record is: 1048 Name TTL IN HTTPS SvcPriority TargetName SvcParams 1050 As with SVCB, the record is defined specifically within the Internet 1051 ("IN") Class [RFC1035]. 1053 All the SvcParamKeys defined in Section 6 are permitted for use in 1054 HTTPS RRs. The default set of ALPN IDs is the single value 1055 "http/1.1". The "automatically mandatory" keys (Section 7) are 1056 "port", "alpn", and "no-default-alpn". 1058 The presence of an HTTPS RR for an origin also indicates that all 1059 HTTP resources are available over HTTPS, as discussed in Section 8.5. 1060 This allows HTTPS RRs to apply to pre-existing "http" scheme URLs, 1061 while ensuring that the client uses a secure and authenticated HTTPS 1062 connection. 1064 The HTTPS RR parallels the concepts introduced in the HTTP 1065 Alternative Services proposed standard [AltSvc]. Clients and servers 1066 that implement HTTPS RRs are not required to implement Alt-Svc. 1068 8.1. Query names for HTTPS RRs 1070 The HTTPS RR uses Port Prefix Naming (Section 2.3), with one 1071 modification: if the scheme is "https" and the port is 443, then the 1072 client's original QNAME is equal to the service name (i.e. the 1073 origin's hostname), without any prefix labels. 1075 By removing the Attrleaf labels [Attrleaf] used in SVCB, this 1076 construction enables offline DNSSEC signing of wildcard domains, 1077 which are commonly used with HTTPS. Reusing the service name also 1078 allows the targets of existing CNAME chains (e.g. CDN hosts) to 1079 start returning HTTPS RR responses without requiring origin domains 1080 to configure and maintain an additional delegation. 1082 Following of HTTPS AliasMode RRs and CNAME aliases is unchanged from 1083 SVCB. 1085 Clients always convert "http" URLs to "https" before performing an 1086 HTTPS RR query using the process described in Section 8.5, so domain 1087 owners MUST NOT publish HTTPS RRs with a prefix of "_http". 1089 Note that none of these forms alter the HTTPS origin or authority. 1090 For example, clients MUST continue to validate TLS certificate 1091 hostnames based on the origin. 1093 8.2. Relationship to Alt-Svc 1095 Publishing a ServiceMode HTTPS RR in DNS is intended to be similar to 1096 transmitting an Alt-Svc field value over HTTPS, and receiving an 1097 HTTPS RR is intended to be similar to receiving that field value over 1098 HTTPS. However, there are some differences in the intended client 1099 and server behavior. 1101 8.2.1. ALPN usage 1103 Unlike Alt-Svc Field Values, HTTPS RRs can contain multiple ALPN IDs, 1104 and clients are encouraged to offer additional ALPNs that they 1105 support (subject to security constraints). 1107 8.2.2. Untrusted channel 1109 SVCB does not require or provide any assurance of authenticity. 1110 (DNSSEC signing and verification, which would provide such assurance, 1111 are OPTIONAL.) The DNS resolution process is treated as an untrusted 1112 channel that learns only the QNAME, and is prevented from mounting 1113 any attack beyond denial of service. 1115 Alt-Svc parameters that cannot be safely received in this model MUST 1116 NOT have a corresponding defined SvcParamKey. For example, there is 1117 no SvcParamKey corresponding to the Alt-Svc "persist" parameter, 1118 because this parameter is not safe to accept over an untrusted 1119 channel. 1121 8.2.3. Cache lifetime 1123 There is no SvcParamKey corresponding to the Alt-Svc "ma" (max age) 1124 parameter. Instead, server operators encode the expiration time in 1125 the DNS TTL. 1127 The appropriate TTL value might be different from the "ma" value used 1128 for Alt-Svc, depending on the desired efficiency and agility. Some 1129 DNS caches incorrectly extend the lifetime of DNS records beyond the 1130 stated TTL, so server operators cannot rely on HTTPS RRs expiring on 1131 time. Shortening the TTL to compensate for incorrect caching is NOT 1132 RECOMMENDED, as this practice impairs the performance of correctly 1133 functioning caches and does not guarantee faster expiration from 1134 incorrect caches. Instead, server operators SHOULD maintain 1135 compatibility with expired records until they observe that nearly all 1136 connections have migrated to the new configuration. 1138 8.2.4. Granularity 1140 Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc 1141 Field Value specifically to the client. When using an HTTPS RR, 1142 groups of clients will necessarily receive the same SvcParams. 1143 Therefore, HTTPS RRs are not suitable for uses that require single- 1144 client granularity. 1146 8.3. Interaction with Alt-Svc 1148 Clients that do not implement support for Encrypted ClientHello MAY 1149 skip the HTTPS RR query if a usable Alt-Svc value is available in the 1150 local cache. If Alt-Svc connection fails, these clients SHOULD fall 1151 back to the HTTPS RR client connection procedure (Section 3). 1153 For clients that implement support for ECH, the interaction between 1154 HTTPS RRs and Alt-Svc is described in Section 9.1. 1156 This specification does not alter the DNS queries performed when 1157 connecting to an Alt-Svc hostname (typically A and/or AAAA only). 1159 8.4. Requiring Server Name Indication 1161 Clients MUST NOT use an HTTPS RR response unless the client supports 1162 TLS Server Name Indication (SNI) and indicate the origin name when 1163 negotiating TLS. This supports the conservation of IP addresses. 1165 Note that the TLS SNI (and also the HTTP "Host" or ":authority") will 1166 indicate the origin, not the TargetName. 1168 8.5. HTTP Strict Transport Security 1170 By publishing a usable HTTPS RR, the server operator indicates that 1171 all useful HTTP resources on that origin are reachable over HTTPS, 1172 similar to HTTP Strict Transport Security [HSTS]. 1174 Prior to making an "http" scheme request, the client SHOULD perform a 1175 lookup to determine if any HTTPS RRs exist for that origin. To do 1176 so, the client SHOULD construct a corresponding "https" URL as 1177 follows: 1179 1. Replace the "http" scheme with "https". 1181 2. If the "http" URL explicitly specifies port 80, specify port 443. 1183 3. Do not alter any other aspect of the URL. 1185 This construction is equivalent to Section 8.3 of [HSTS], point 5. 1187 If an HTTPS RR query for this "https" URL returns any AliasMode HTTPS 1188 RRs, or any compatible ServiceMode HTTPS RRs (see Section 7), the 1189 client SHOULD act as if it has received an HTTP "307 Temporary 1190 Redirect" redirect to this "https" URL. (Receipt of an incompatible 1191 ServiceMode RR does not trigger the redirect behavior.) Because 1192 HTTPS RRs are received over an often insecure channel (DNS), clients 1193 MUST NOT place any more trust in this signal than if they had 1194 received a 307 redirect over cleartext HTTP. 1196 When making an "https" scheme request to an origin with an HTTPS RR, 1197 either directly or via the above redirect, the client SHOULD 1198 terminate the connection if there are any errors with the underlying 1199 secure transport, such as errors in certificate validation. This 1200 aligns with Section 8.4 and Section 12.1 of [HSTS]. 1202 8.6. HTTP-based protocols 1204 All protocols employing "http://" or "https://" URLs SHOULD respect 1205 HTTPS RRs. For example, clients that support HTTPS RRs and implement 1206 the altered WebSocket [WebSocket] opening handshake from the W3C 1207 Fetch specification [FETCH] SHOULD use HTTPS RRs for the 1208 "requestURL". 1210 An HTTP-based protocol MAY define its own SVCB mapping. Such 1211 mappings MAY be defined to take precedence over HTTPS RRs. 1213 9. SVCB/HTTPS RR parameter for ECH configuration 1215 The SVCB "echconfig" parameter is defined for conveying the ECH 1216 configuration of an alternative endpoint. In wire format, the value 1217 of the parameter is an ECHConfigs vector [ECH], including the 1218 redundant length prefix. In presentation format, the value is a 1219 single ECHConfigs encoded in Base64 [base64]. Base64 is used here to 1220 simplify integration with TLS server software. To enable simpler 1221 parsing, this SvcParam MUST NOT contain escape sequences. 1223 When ECH is in use, the TLS ClientHello is divided into an 1224 unencrypted "outer" and an encrypted "inner" ClientHello. The outer 1225 ClientHello is an implementation detail of ECH, and its contents are 1226 controlled by the ECHConfig in accordance with [ECH]. The inner 1227 ClientHello is used for establishing a connection to the service, so 1228 its contents may be influenced by other SVCB parameters. For 1229 example, the requirements on the ProtocolNameList in Section 6.1 1230 apply only to the inner ClientHello. Similarly, it is the inner 1231 ClientHello whose Server Name Indication identifies the desired 1232 service. 1234 9.1. Client behavior 1236 The general client behavior specified in Section 3 permits clients to 1237 retry connection with a less preferred alternative if the preferred 1238 option fails, including falling back to a direct connection if all 1239 SVCB options fail. This behavior is not suitable for ECH, because 1240 fallback would negate the privacy benefits of ECH. Accordingly, ECH- 1241 capable clients SHALL implement the following behavior for connection 1242 establishment: 1244 1. Perform connection establishment using HTTPS RRs as described in 1245 Section 3. After step 4, if there were compatible HTTPS RRs, 1246 they all had an "echconfig" key, and attempts to connect to them 1247 all failed, terminate connection establishment. 1249 2. If the client implements Alt-Svc, try to connect using any 1250 entries from the Alt-Svc cache. 1252 3. Continue connection establishment as in Section 3 if necessary. 1254 As a latency optimization, clients MAY prefetch DNS records for later 1255 steps before they are needed. 1257 9.2. Deployment considerations 1259 An HTTPS RRSet containing some RRs with "echconfig" and some without 1260 is vulnerable to a downgrade attack. This configuration is NOT 1261 RECOMMENDED. Zone owners who do use such a mixed configuration 1262 SHOULD mark the RRs with "echconfig" as more preferred (i.e. smaller 1263 SvcPriority) than those without, in order to maximize the likelihood 1264 that ECH will be used in the absence of an active adversary. 1266 10. Zone Structures 1268 10.1. Structuring zones for flexibility 1270 Each ServiceForm RRSet can only serve a single scheme. The scheme is 1271 indicated by the owner name and the RR type. For the generic SVCB RR 1272 type, this means that each owner name can only be used for a single 1273 scheme. The underscore prefixing requirement (Section 2.3) ensures 1274 that this is true for the initial query, but it is the responsibility 1275 of zone owners to choose names that satisfy this constraint when 1276 using aliases, including CNAME and AliasMode records. 1278 When using the generic SVCB RR type with aliasing, zone owners SHOULD 1279 choose alias target names that indicate the scheme in use (e.g. 1280 "foosvc.example.net" for "foo://" schemes). This will help to avoid 1281 confusion when another scheme needs to be added to the configuration. 1283 10.2. Structuring zones for performance 1285 To avoid a delay for clients using a nonconforming recursive 1286 resolver, domain owners SHOULD minimize the use of AliasMode records, 1287 and choose TargetName to be a domain for which the client will have 1288 already issued address queries (see Section 3). For 1289 foo://foo.example.com:8080, this might look like: 1291 $ORIGIN example.com. ; Origin 1292 foo 3600 IN CNAME foosvc.example.net. 1293 _8080._foo.foo 3600 IN CNAME foosvc.example.net. 1295 $ORIGIN example.net. ; Service provider zone 1296 foosvc 3600 IN SVCB 1 . key65333=... 1297 foosvc 300 IN AAAA 2001:db8::1 1299 Domain owners SHOULD avoid using a TargetName that is below a DNAME, 1300 as this is likely unnecessary and makes responses slower and larger. 1302 10.3. Examples 1304 10.3.1. Protocol enhancements 1306 Consider a simple zone of the form: 1308 $ORIGIN simple.example. ; Simple example zone 1309 @ 300 IN A 192.0.2.1 1310 AAAA 2001:db8::1 1312 The domain owner could add this record: 1314 simple.example. 7200 IN HTTPS 1 . alpn=h3 1316 to indicate that simple.example uses HTTPS, and supports QUIC in 1317 addition to HTTPS over TCP (an implicit default). The record could 1318 also include other information (e.g. non-standard port, ECH 1319 configuration). 1321 10.3.2. Apex aliasing 1323 Consider a zone that is using CNAME aliasing: 1325 $ORIGIN aliased.example. ; A zone that is using a hosting service 1326 ; Subdomain aliased to a high-performance server pool 1327 www 7200 IN CNAME pool.svc.example. 1328 ; Apex domain on fixed IPs because CNAME is not allowed at the apex 1329 @ 300 IN A 192.0.2.1 1330 IN AAAA 2001:db8::1 1332 With HTTPS RRs, the owner of aliased.example could alias the apex by 1333 adding one additional record: 1335 @ 7200 IN HTTPS 0 pool.svc.example. 1337 With this record in place, HTTPS-RR-aware clients will use the same 1338 server pool for aliased.example and www.aliased.example. (They will 1339 also upgrade to HTTPS on aliased.example.) Non-HTTPS-RR-aware 1340 clients will just ignore the new record. 1342 Similar to CNAME, HTTPS RRs have no impact on the origin name. When 1343 connecting, clients will continue to treat the authoritative origins 1344 as "https://www.aliased.example" and "https://aliased.example", 1345 respectively, and will validate TLS server certificates accordingly. 1347 10.3.3. Parameter binding 1349 Suppose that svc.example's default server pool supports HTTP/2, and 1350 it has deployed HTTP/3 on a new server pool with a different 1351 configuration. This can be expressed in the following form: 1353 $ORIGIN svc.example. ; A hosting provider. 1354 pool 7200 IN HTTPS 1 h3pool alpn=h2,h3 echconfig="123..." 1355 HTTPS 2 . alpn=h2 echconfig="abc..." 1356 pool 300 IN A 192.0.2.2 1357 AAAA 2001:db8::2 1358 h3pool 300 IN A 192.0.2.3 1359 AAAA 2001:db8::3 1361 This configuration is entirely compatible with the "Apex aliasing" 1362 example, whether the client supports HTTPS RRs or not. If the client 1363 does support HTTPS RRs, all connections will be upgraded to HTTPS, 1364 and clients will use HTTP/3 if they can. Parameters are "bound" to 1365 each server pool, so each server pool can have its own protocol, ECH 1366 configuration, etc. 1368 10.3.4. Multi-CDN 1370 The HTTPS RR is intended to support HTTPS services operated by 1371 multiple independent entities, such as different Content Delivery 1372 Networks (CDNs) or different hosting providers. This includes the 1373 case where a service is migrated from one operator to another, as 1374 well as the case where the service is multiplexed between multiple 1375 operators for performance, redundancy, etc. 1377 This example shows such a configuration, with www.customer.example 1378 having different DNS responses to different queries, either over time 1379 or due to logic within the authoritative DNS server: 1381 ; This zone contains/returns different CNAME records 1382 ; at different points-in-time. The RRset for "www" can 1383 ; only ever contain a single CNAME. 1385 ; Sometimes the zone has: 1386 $ORIGIN customer.example. ; A Multi-CDN customer domain 1387 www 900 IN CNAME cdn1.svc1.example. 1389 ; and other times it contains: 1390 $ORIGIN customer.example. 1391 www 900 IN CNAME customer.svc2.example. 1393 ; and yet other times it contains: 1394 $ORIGIN customer.example. 1395 www 900 IN CNAME cdn3.svc3.example. 1397 ; With the following remaining constant and always included: 1398 $ORIGIN customer.example. ; A Multi-CDN customer domain 1399 ; The apex is also aliased to www to match its configuration 1400 @ 7200 IN HTTPS 0 www 1401 ; Non-HTTPS-aware clients use non-CDN IPs 1402 A 203.0.113.82 1403 AAAA 2001:db8:203::2 1405 ; Resolutions following the cdn1.svc1.example 1406 ; path use these records. 1407 ; This CDN uses a different alternative service for HTTP/3. 1408 $ORIGIN svc1.example. ; domain for CDN 1 1409 cdn1 1800 IN HTTPS 1 h3pool alpn=h3 echconfig="123..." 1410 HTTPS 2 . alpn=h2 echconfig="123..." 1411 A 192.0.2.2 1412 AAAA 2001:db8:192::4 1413 h3pool 300 IN A 192.0.2.3 1414 AAAA 2001:db8:192:7::3 1416 ; Resolutions following the customer.svc2.example 1417 ; path use these records. 1418 ; Note that this CDN only supports HTTP/2. 1419 $ORIGIN svc2.example. ; domain operated by CDN 2 1420 customer 300 IN HTTPS 1 . alpn=h2 echconfig="xyz..." 1421 60 IN A 198.51.100.2 1422 A 198.51.100.3 1423 A 198.51.100.4 1424 AAAA 2001:db8:198::7 1425 AAAA 2001:db8:198::12 1427 ; Resolutions following the customer.svc2.example 1428 ; path use these records. 1430 ; Note that this CDN has no HTTPS records 1431 ; and thus no ECH support. 1432 $ORIGIN svc3.example. ; domain operated by CDN 3 1433 cdn3 60 IN A 203.0.113.8 1434 AAAA 2001:db8:113::8 1436 Note that in the above example, the different CDNs have different 1437 echconfig and different capabilities, but clients will use HTTPS RRs 1438 as a bound-together unit. 1440 Domain owners should be cautious when using a multi-CDN 1441 configuration, as it introduces a number of complexities highlighted 1442 by this example: 1444 o If CDN 1 supports ECH, and CDN 2 does not, the client is 1445 vulnerable to ECH downgrade by a network adversary who forces 1446 clients to get CDN 2 records. 1448 o Aliasing the apex to its subdomain simplifies the zone file but 1449 likely increases resolution latency, especially when using a non- 1450 HTTPS-aware recursive resolver. An alternative would be to alias 1451 the zone apex directly to a name managed by a CDN. 1453 o The A, AAAA, HTTPS resolutions are independent lookups so clients 1454 may observe and follow different CNAMEs to different CDNs. 1455 Clients may thus find a SvcDomainName pointing to a name other 1456 than the one which returned along with the A and AAAA lookups and 1457 will need to do an additional resolution for them. Including 1458 ipv6hint and ipv4hint will reduce the performance impact of this 1459 case. 1461 o If not all CDNs publish HTTPS records, clients will sometimes 1462 receive NODATA for HTTPS queries (as with cdn3.svc3.example 1463 above), and thus no echconfig, but could receive A/AAAA records 1464 from a different CDN which does support ECH. Clients will be 1465 unable to use ECH in this case. 1467 10.3.5. Non-HTTPS uses 1469 For services other than HTTPS, the SVCB RR and an Attrleaf label 1470 [Attrleaf] will be used. For example, to reach an example resource 1471 of "baz://api.example.com:8765", the following SVCB record would be 1472 used to alias it to "svc4-baz.example.net." which in-turn could 1473 return AAAA/A records and/or SVCB records in ServiceMode: 1475 _8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net. 1477 HTTPS RRs use similar Attrleaf labels if the origin contains a non- 1478 default port. 1480 11. Interaction with other standards 1482 This standard is intended to reduce connection latency and improve 1483 user privacy. Server operators implementing this standard SHOULD 1484 also implement TLS 1.3 [RFC8446] and OCSP Stapling [RFC6066], both of 1485 which confer substantial performance and privacy benefits when used 1486 in combination with SVCB records. 1488 To realize the greatest privacy benefits, this proposal is intended 1489 for use over a privacy-preserving DNS transport (like DNS over TLS 1490 [DoT] or DNS over HTTPS [DoH]). However, performance improvements, 1491 and some modest privacy improvements, are possible without the use of 1492 those standards. 1494 Any specification for use of SVCB with a protocol MUST have an entry 1495 for its scheme under the SVCB RR type in the IANA DNS Underscore 1496 Global Scoped Entry Registry [Attrleaf]. The scheme SHOULD have an 1497 entry in the IANA URI Schemes Registry [RFC7595]. The scheme SHOULD 1498 have a defined specification for use with SVCB. 1500 12. Security Considerations 1502 SVCB/HTTPS RRs are intended for distribution over untrusted channels, 1503 and clients are REQUIRED to verify that the alternative endpoint is 1504 authoritative for the service (similar to Section 2.1 of [AltSvc]). 1505 Therefore, DNSSEC signing and validation are OPTIONAL for publishing 1506 and using SVCB and HTTPS RRs. 1508 Clients MUST ensure that their DNS cache is partitioned for each 1509 local network, or flushed on network changes, to prevent a local 1510 adversary in one network from implanting a forged DNS record that 1511 allows them to track users or hinder their connections after they 1512 leave that network. 1514 An attacker who can prevent SVCB resolution can deny clients any 1515 associated security benefits. A hostile recursive resolver can 1516 always deny service to SVCB queries, but network intermediaries can 1517 often prevent resolution as well, even when the client and recursive 1518 resolver validate DNSSEC and use a secure transport. These downgrade 1519 attacks can prevent the HTTPS upgrade provided by the HTTPS RR 1520 (Section 8.5), and disable the encryption enabled by the echconfig 1521 SvcParamKey (Section 9). To prevent downgrades, Section 3.1 1522 recommends that clients abandon the connection attempt when such an 1523 attack is detected. 1525 A hostile DNS intermediary might forge AliasForm "." records 1526 (Section 2.5.1) as a way to block clients from accessing particular 1527 services. Such an adversary could already block entire domains by 1528 forging erroneous responses, but this mechanism allows them to target 1529 particular protocols or ports within a domain. Clients that might be 1530 subject to such attacks SHOULD ignore AliasForm "." records. 1532 13. Privacy Considerations 1534 Standard address queries reveal the user's intent to access a 1535 particular domain. This information is visible to the recursive 1536 resolver, and to many other parties when plaintext DNS transport is 1537 used. SVCB queries, like queries for SRV records and other specific 1538 RR types, additionally reveal the user's intent to use a particular 1539 protocol. This is not normally sensitive information, but it should 1540 be considered when adding SVCB support in a new context. 1542 14. IANA Considerations 1544 14.1. SVCB RRType 1546 This document defines a new DNS RR type, SVCB, whose value 64 has 1547 been allocated by IANA from the "Resource Record (RR) TYPEs" 1548 subregistry of the "Domain Name System (DNS) Parameters" registry: 1550 Type: SVCB 1552 Value: 64 1554 Meaning: General Purpose Service Endpoints 1556 Reference: This document 1558 14.2. HTTPS RRType 1560 This document defines a new DNS RR type, HTTPS, whose value 65 has 1561 been allocated by IANA from the "Resource Record (RR) TYPEs" 1562 subregistry of the "Domain Name System (DNS) Parameters" registry: 1564 Type: HTTPS 1566 Value: 65 1568 Meaning: HTTPS Specific Service Endpoints 1570 Reference: This document 1572 14.3. New registry for Service Parameters 1574 The "Service Binding (SVCB) Parameter Registry" defines the namespace 1575 for parameters, including string representations and numeric 1576 SvcParamKey values. This registry is shared with other SVCB- 1577 compatible RR types, such as the HTTPS RR. 1579 ACTION: create and include a reference to this registry. 1581 14.3.1. Procedure 1583 A registration MUST include the following fields: 1585 o Number: SvcParamKey wire format numeric identifier (range 0-65535) 1587 o Name: SvcParamKey presentation name 1589 o Meaning: a short description 1591 o Pointer to specification text 1593 SvcParamKey entries to be added to this namespace have different 1594 policies ([RFC8126], Section 4) based on their range: 1596 +-------------+-------------------------+ 1597 | Number | IANA Policy | 1598 +-------------+-------------------------+ 1599 | 0-255 | Standards Action | 1600 | | | 1601 | 256-32767 | Expert Review | 1602 | | | 1603 | 32768-65280 | First Come First Served | 1604 | | | 1605 | 65280-65534 | Private Use | 1606 | | | 1607 | 65535 | Standards Action | 1608 +-------------+-------------------------+ 1610 Apart from the initial contents, the SvcParamKey name MUST NOT start 1611 with "key". 1613 14.3.2. Initial contents 1615 The "Service Binding (SVCB) Parameter Registry" shall initially be 1616 populated with the registrations below: 1618 +-------------+-----------------+----------------------+------------+ 1619 | Number | Name | Meaning | Reference | 1620 +-------------+-----------------+----------------------+------------+ 1621 | 0 | mandatory | Mandatory keys in | (This | 1622 | | | this RR | document) | 1623 | | | | | 1624 | 1 | alpn | Additional supported | (This | 1625 | | | protocols | document) | 1626 | | | | | 1627 | 2 | no-default-alpn | No support for | (This | 1628 | | | default protocol | document) | 1629 | | | | | 1630 | 3 | port | Port for alternative | (This | 1631 | | | endpoint | document) | 1632 | | | | | 1633 | 4 | ipv4hint | IPv4 address hints | (This | 1634 | | | | document) | 1635 | | | | | 1636 | 5 | echconfig | Encrypted | (This | 1637 | | | ClientHello info | document) | 1638 | | | | | 1639 | 6 | ipv6hint | IPv6 address hints | (This | 1640 | | | | document) | 1641 | | | | | 1642 | 65280-65534 | keyNNNNN | Private Use | (This | 1643 | | | | document) | 1644 | | | | | 1645 | 65535 | key65535 | Reserved ("Invalid | (This | 1646 | | | key") | document) | 1647 +-------------+-----------------+----------------------+------------+ 1649 14.4. Registry updates 1651 Per [RFC6895], please add the following entries to the data type 1652 range of the Resource Record (RR) TYPEs registry: 1654 +-------+------------------------------------------+----------------+ 1655 | TYPE | Meaning | Reference | 1656 +-------+------------------------------------------+----------------+ 1657 | SVCB | Service Location and Parameter Binding | (This | 1658 | | | document) | 1659 | | | | 1660 | HTTPS | HTTPS Service Location and Parameter | (This | 1661 | | Binding | document) | 1662 +-------+------------------------------------------+----------------+ 1664 Per [Attrleaf], please add the following entry to the DNS Underscore 1665 Global Scoped Entry Registry: 1667 +---------+------------+-----------------+-----------------+ 1668 | RR TYPE | _NODE NAME | Meaning | Reference | 1669 +---------+------------+-----------------+-----------------+ 1670 | HTTPS | _https | HTTPS SVCB info | (This document) | 1671 +---------+------------+-----------------+-----------------+ 1673 15. Acknowledgments and Related Proposals 1675 There have been a wide range of proposed solutions over the years to 1676 the "CNAME at the Zone Apex" challenge proposed. These include 1677 [I-D.bellis-dnsop-http-record], [I-D.ietf-dnsop-aname], and others. 1679 Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thomson, Lucas 1680 Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, David 1681 Benjamin, Mark Andrews, Emily Stark, Eric Orth, Kyle Rose, Craig 1682 Taylor, Dan McArdle, Brian Dickson, and others for their feedback and 1683 suggestions on this draft. 1685 16. References 1687 16.1. Normative References 1689 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1690 "Transport Layer Security (TLS) Application-Layer Protocol 1691 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1692 July 2014, . 1694 [Attrleaf] 1695 Crocker, D., "Scoped Interpretation of DNS Resource 1696 Records through "Underscored" Naming of Attribute Leaves", 1697 BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, 1698 . 1700 [base64] Josefsson, S., "The Base16, Base32, and Base64 Data 1701 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1702 . 1704 [DNAME] Rose, S. and W. Wijngaards, "DNAME Redirection in the 1705 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 1706 . 1708 [DoH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1709 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1710 . 1712 [DoT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1713 and P. Hoffman, "Specification for DNS over Transport 1714 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1715 2016, . 1717 [ECH] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 1718 Encrypted Client Hello", draft-ietf-tls-esni-08 (work in 1719 progress), October 2020. 1721 [HappyEyeballsV2] 1722 Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1723 Better Connectivity Using Concurrency", RFC 8305, 1724 DOI 10.17487/RFC8305, December 2017, 1725 . 1727 [HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1728 Transport Security (HSTS)", RFC 6797, 1729 DOI 10.17487/RFC6797, November 2012, 1730 . 1732 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 1733 (HTTP/3)", draft-ietf-quic-http-32 (work in progress), 1734 October 2020. 1736 [RFC1035] Mockapetris, P., "Domain names - implementation and 1737 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1738 November 1987, . 1740 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1741 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1742 DOI 10.17487/RFC1928, March 1996, 1743 . 1745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1746 Requirement Levels", BCP 14, RFC 2119, 1747 DOI 10.17487/RFC2119, March 1997, 1748 . 1750 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 1751 RFC 3225, DOI 10.17487/RFC3225, December 2001, 1752 . 1754 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 1755 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 1756 2003, . 1758 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1759 Specifications: ABNF", STD 68, RFC 5234, 1760 DOI 10.17487/RFC5234, January 2008, 1761 . 1763 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1764 Address Text Representation", RFC 5952, 1765 DOI 10.17487/RFC5952, August 2010, 1766 . 1768 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1769 Extensions: Extension Definitions", RFC 6066, 1770 DOI 10.17487/RFC6066, January 2011, 1771 . 1773 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1774 Beijnum, "DNS64: DNS Extensions for Network Address 1775 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1776 DOI 10.17487/RFC6147, April 2011, 1777 . 1779 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1780 the IPv6 Prefix Used for IPv6 Address Synthesis", 1781 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1782 . 1784 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1785 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1786 DOI 10.17487/RFC7231, June 2014, 1787 . 1789 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 1790 and Registration Procedures for URI Schemes", BCP 35, 1791 RFC 7595, DOI 10.17487/RFC7595, June 2015, 1792 . 1794 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1795 Writing an IANA Considerations Section in RFCs", BCP 26, 1796 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1797 . 1799 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1800 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1801 May 2017, . 1803 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1804 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1805 . 1807 [WebSocket] 1808 Fette, I. and A. Melnikov, "The WebSocket Protocol", 1809 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1810 . 1812 16.2. Informative References 1814 [AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1815 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1816 April 2016, . 1818 [DNSTerm] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1819 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1820 January 2019, . 1822 [FETCH] "Fetch Living Standard", May 2020, 1823 . 1825 [I-D.bellis-dnsop-http-record] 1826 Bellis, R., "A DNS Resource Record for HTTP", draft- 1827 bellis-dnsop-http-record-00 (work in progress), November 1828 2018. 1830 [I-D.ietf-dnsop-aname] 1831 Finch, T., Hunt, E., Dijk, P., Eden, A., and W. Mekking, 1832 "Address-specific DNS aliases (ANAME)", draft-ietf-dnsop- 1833 aname-04 (work in progress), July 2019. 1835 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1836 DOI 10.17487/RFC6454, December 2011, 1837 . 1839 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 1840 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 1841 April 2013, . 1843 [SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1844 specifying the location of services (DNS SRV)", RFC 2782, 1845 DOI 10.17487/RFC2782, February 2000, 1846 . 1848 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1849 Resource Identifier (URI): Generic Syntax", STD 66, 1850 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1851 . 1853 16.3. URIs 1855 [1] https://github.com/MikeBishop/dns-alt-svc 1857 Appendix A. Decoding text in zone files 1859 DNS zone files are capable of representing arbitrary octet sequences 1860 in basic ASCII text, using various delimiters and encodings. The 1861 algorithm for decoding these character-strings is defined in 1862 Section 5.1 of [RFC1035]. Here we summarize the allowed input to 1863 that algorithm, using ABNF: 1865 ; non-special is VCHAR minus DQUOTE, ";", "(", ")", and "\". 1866 non-special = %x21 / %x23-27 / %x2A-3A / %x3C-5B / %x5D-7E 1867 ; non-digit is VCHAR minus DIGIT 1868 non-digit = %x21-2F / %x3A-7E 1869 ; dec-octet is a number 0-255 as a three-digit decimal number. 1870 dec-octet = ( "0" / "1" ) 2DIGIT / 1871 "2" ( ( %x30-34 DIGIT ) / ( "5" %x30-35 ) ) 1872 escaped = "\" ( non-digit / dec-octet ) 1873 contiguous = 1*( non-special / escaped ) 1874 quoted = DQUOTE *( contiguous / ( ["\"] WSP ) ) DQUOTE 1875 char-string = contiguous / quoted 1877 The decoding algorithm allows "char-string" to represent any 1878 "*OCTET". In this document, this algorithm is referred to as 1879 "character-string decoding". The algorithm is the same as used by 1880 "" in RFC 1035, although the output length in this 1881 document is not limited to 255 octets. 1883 A.1. Decoding a value-list 1885 In order to represent lists of values in zone files, this 1886 specification uses an extended version of character-string decoding 1887 that adds the use of "," as a delimiter after double-quote 1888 processing. When "," is not escaped (by a preceding "\" or as the 1889 escape sequence "\044"), it separates values in the output, which is 1890 a list of 1*OCTET. (For simplicity, empty values are not allowed.) 1891 We refer to this modified procedure as "value-list decoding". 1893 value-list = char-string 1894 list-value = 1*OCTET 1896 For example, consider these "char-string" SvcParamValues: 1898 "part1,part2\,part3" 1899 part1,part2\044part3 1900 Character-string decoding either of these inputs would produce a 1901 single "*OCTET" output: 1903 part1,part2,part3 1905 Value-list decoding either of these inputs would instead convert it 1906 to a list of two "list-value"s: 1908 part1 1909 part2,part3 1911 Appendix B. Comparison with alternatives 1913 The SVCB and HTTPS RR types closely resemble, and are inspired by, 1914 some existing record types and proposals. A complaint with all of 1915 the alternatives is that web clients have seemed unenthusiastic about 1916 implementing them. The hope here is that by providing an extensible 1917 solution that solves multiple problems we will overcome the inertia 1918 and have a path to achieve client implementation. 1920 B.1. Differences from the SRV RR type 1922 An SRV record [SRV] can perform a similar function to the SVCB 1923 record, informing a client to look in a different location for a 1924 service. However, there are several differences: 1926 o SRV records are typically mandatory, whereas clients will always 1927 continue to function correctly without making use of SVCB. 1929 o SRV records cannot instruct the client to switch or upgrade 1930 protocols, whereas SVCB can signal such an upgrade (e.g. to 1931 HTTP/2). 1933 o SRV records are not extensible, whereas SVCB and HTTPS RRs can be 1934 extended with new parameters. 1936 o SVCB records use 16 bit for SvcPriority for consistency with SRV 1937 and other RR types that also use 16 bit priorities. 1939 B.2. Differences from the proposed HTTP record 1941 Unlike [I-D.bellis-dnsop-http-record], this approach is extensible to 1942 cover Alt-Svc and Encrypted ClientHello use-cases. Like that 1943 proposal, this addresses the zone apex CNAME challenge. 1945 Like that proposal, it remains necessary to continue to include 1946 address records at the zone apex for legacy clients. 1948 B.3. Differences from the proposed ANAME record 1950 Unlike [I-D.ietf-dnsop-aname], this approach is extensible to cover 1951 Alt-Svc and ECH use-cases. This approach also does not require any 1952 changes or special handling on either authoritative or primary 1953 servers, beyond optionally returning in-bailiwick additional records. 1955 Like that proposal, this addresses the zone apex CNAME challenge for 1956 clients that implement this. 1958 However, with this SVCB proposal, it remains necessary to continue to 1959 include address records at the zone apex for legacy clients. If 1960 deployment of this standard is successful, the number of legacy 1961 clients will fall over time. As the number of legacy clients 1962 declines, the operational effort required to serve these users 1963 without the benefit of SVCB indirection should fall. Server 1964 operators can easily observe how much traffic reaches this legacy 1965 endpoint, and may remove the apex's address records if the observed 1966 legacy traffic has fallen to negligible levels. 1968 B.4. Comparison with separate RR types for AliasMode and ServiceMode 1970 Abstractly, functions of AliasMode and ServiceMode are independent, 1971 so it might be tempting to specify them as separate RR types. 1972 However, this would result in a serious performance impairment, 1973 because clients cannot rely on their recursive resolver to follow 1974 SVCB aliases (unlike CNAME). Thus, clients would have to issue 1975 queries for both RR types in parallel, potentially at each step of 1976 the alias chain. Recursive resolvers that implement the 1977 specification would, upon receipt of a ServiceMode query, emit both a 1978 ServiceMode and an AliasMode query to the authoritative. Thus, 1979 splitting the RR type would double, or in some cases triple, the load 1980 on clients and servers, and would not reduce implementation 1981 complexity. 1983 Appendix C. Change history 1985 o draft-ietf-dnsop-svcb-https-02 1987 * Added a Privacy Considerations section 1989 * Adjusted resolution fallback description 1991 * Clarified status of SvcParams in AliasMode 1993 * Improved advice on zone structuring and use with Alt-Svc 1995 * Improved examples, including a new Multi-CDN example 1996 * Reorganized text on value-list parsing and SvcPriority 1998 * Improved phrasing and other editorial improvements throughout 2000 o draft-ietf-dnsop-svcb-https-01 2002 * Added a "mandatory" SvcParamKey 2004 * Added the ability to indicate that a service does not exist 2006 * Adjusted resolution and ALPN algorithms 2008 * Major terminology revisions for "origin" and CamelCase names 2010 * Revised ABNF 2012 * Include allocated RR type numbers 2014 * Various corrections, explanations, and recommendations 2016 o draft-ietf-dnsop-svcb-https-00 2018 * Rename HTTPSSVC RR to HTTPS RR 2020 * Rename "an SVCB" to "a SVCB" 2022 * Removed "design considerations and open issues" section and 2023 some other "to be removed" text 2025 o draft-ietf-dnsop-svcb-httpssvc-03 2027 * Revised chain length limit requirements 2029 * Revised IANA registry rules for SvcParamKeys 2031 * Require HTTPS clients to implement SNI 2033 * Update terminology for Encrypted ClientHello 2035 * Clarifications: non-default ports, transport proxies, HSTS 2036 procedure, WebSocket behavior, wire format, IP hints, inner/ 2037 outer ClientHello with ECH 2039 * Various textual and ABNF corrections 2041 o draft-ietf-dnsop-svcb-httpssvc-02 2043 * All changes to Alt-Svc have been removed 2044 * Expanded and reorganized examples 2046 * Priority zero is now the definition of AliasForm 2048 * Repeated SvcParamKeys are no longer allowed 2050 * The "=" sign may be omitted in a key=value pair if the value is 2051 also empty 2053 * In the wire format, SvcParamKeys must be in sorted order 2055 * New text regarding how to handle resolution timeouts 2057 * Expanded description of recursive resolver behavior 2059 * Much more precise description of the intended ALPN behavior 2061 * Match the HSTS specification's language on HTTPS enforcement 2063 * Removed 'esniconfig=""' mechanism and simplified ESNI 2064 connection logic 2066 o draft-ietf-dnsop-svcb-httpssvc-01 2068 * Reduce the emphasis on conversion between HTTPSSVC and Alt-Svc 2070 * Make the "untrusted channel" concept more precise. 2072 * Make SvcFieldPriority = 0 the definition of AliasForm, instead 2073 of a requirement. 2075 o draft-ietf-dnsop-svcb-httpssvc-00 2077 * Document an optimization for optimistic pre-connection. (Chris 2078 Wood) 2080 * Relax IP hint handling requirements. (Eric Rescorla) 2082 o draft-nygren-dnsop-svcb-httpssvc-00 2084 * Generalize to an SVCB record, with special-case handling for 2085 Alt-Svc and HTTPS separated out to dedicated sections. 2087 * Split out a separate HTTPSSVC record for the HTTPS use-case. 2089 * Remove the explicit SvcRecordType=0/1 and instead make the 2090 AliasForm vs ServiceForm be implicit. This was based on 2091 feedback recommending against subtyping RR type. 2093 * Remove one optimization. 2095 o draft-nygren-httpbis-httpssvc-03 2097 * Change redirect type for HSTS-style behavior from 302 to 307 to 2098 reduce ambiguities. 2100 o draft-nygren-httpbis-httpssvc-02 2102 * Remove the redundant length fields from the wire format. 2104 * Define a SvcDomainName of "." for SvcRecordType=1 as being the 2105 HTTPSSVC RRNAME. 2107 * Replace "hq" with "h3". 2109 o draft-nygren-httpbis-httpssvc-01 2111 * Fixes of record name. Replace references to "HTTPSVC" with 2112 "HTTPSSVC". 2114 o draft-nygren-httpbis-httpssvc-00 2116 * Initial version 2118 Authors' Addresses 2120 Ben Schwartz 2121 Google 2123 Email: bemasc@google.com 2125 Mike Bishop 2126 Akamai Technologies 2128 Email: mbishop@evequefou.be 2130 Erik Nygren 2131 Akamai Technologies 2133 Email: erik+ietf@nygren.org