idnits 2.17.1 draft-ietf-dnsop-svcb-httpssvc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (November 4, 2019) is 1607 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-04 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-20 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Duplicate reference: RFC7838, mentioned in 'RFC7838', was also mentioned in 'AltSvc'. -- Obsolete informational reference (is this intentional?): RFC 8499 (ref. 'DNSTerm') (Obsoleted by RFC 9499) -- Obsolete informational reference (is this intentional?): RFC 7230 (ref. 'HTTP') (Obsoleted by RFC 9110, RFC 9112) == Outdated reference: A later version (-04) exists of draft-ietf-dnsop-aname-03 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 5 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 7, 2020 E. Nygren 6 Akamai Technologies 7 November 4, 2019 9 Service binding and parameter specification via the DNS (DNS SVCB and 10 HTTPSSVC) 11 draft-ietf-dnsop-svcb-httpssvc-01 13 Abstract 15 This document specifies the "SVCB" and "HTTPSSVC" DNS resource record 16 types to facilitate the lookup of information needed to make 17 connections for origin resources, such as for HTTPS URLs. SVCB 18 records allow an origin to be served from multiple network locations, 19 each with associated parameters (such as transport protocol 20 configuration and keying material for encrypting TLS SNI). They also 21 enable aliasing of apex domains, which is not possible with CNAME. 22 The HTTPSSVC DNS RR is a variation of SVCB for HTTPS and HTTP 23 origins. By providing more information to the client before it 24 attempts to establish a connection, these records offer potential 25 benefits to both performance and privacy. 27 TO BE REMOVED: This proposal is inspired by and based on recent DNS 28 usage proposals such as ALTSVC, ANAME, and ESNIKEYS (as well as long 29 standing desires to have SRV or a functional equivalent implemented 30 for HTTP). These proposals each provide an important function but 31 are potentially incompatible with each other, such as when an origin 32 is load-balanced across multiple hosting providers (multi-CDN). 33 Furthermore, these each add potential cases for adding additional 34 record lookups in-addition to AAAA/A lookups. This design attempts 35 to provide a unified framework that encompasses the key functionality 36 of these proposals, as well as providing some extensibility for 37 addressing similar future challenges. 39 TO BE REMOVED: The specific name for this RR type is an open topic 40 for discussion. "SVCB" and "HTTPSSVC" are meant as placeholders as 41 they are easy to replace. Other names might include "B", "SRV2", 42 "SVCHTTPS", "HTTPS", and "ALTSVC". 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on May 7, 2020. 61 Copyright Notice 63 Copyright (c) 2019 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (https://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.1. Introductory Example . . . . . . . . . . . . . . . . . . 5 80 1.2. Goals of the SVCB RR . . . . . . . . . . . . . . . . . . 6 81 1.3. Overview of the SVCB RR . . . . . . . . . . . . . . . . . 7 82 1.4. Parameter for ESNI . . . . . . . . . . . . . . . . . . . 8 83 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 84 2. The SVCB record type . . . . . . . . . . . . . . . . . . . . 8 85 2.1. Parameter specification via ServiceFieldValue . . . . . . 9 86 2.1.1. Presentation format . . . . . . . . . . . . . . . . . 9 87 2.2. SVCB RDATA Wire Format . . . . . . . . . . . . . . . . . 10 88 2.3. SVCB owner names . . . . . . . . . . . . . . . . . . . . 10 89 2.4. SvcRecordType . . . . . . . . . . . . . . . . . . . . . . 11 90 2.5. SVCB records: AliasForm . . . . . . . . . . . . . . . . . 11 91 2.6. SVCB records: ServiceForm . . . . . . . . . . . . . . . . 12 92 2.6.1. Special handling of "." for SvcDomainName in 93 ServiceForm . . . . . . . . . . . . . . . . . . . . . 12 94 2.6.2. SvcFieldPriority . . . . . . . . . . . . . . . . . . 13 95 3. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 13 96 3.1. Clients using a Proxy . . . . . . . . . . . . . . . . . . 14 98 4. DNS Server Behavior . . . . . . . . . . . . . . . . . . . . . 14 99 5. Performance optimizations . . . . . . . . . . . . . . . . . . 15 100 5.1. Optimistic pre-connection and connection reuse . . . . . 15 101 5.2. Preferring usable records . . . . . . . . . . . . . . . . 16 102 5.3. Structuring zones for performance . . . . . . . . . . . . 16 103 6. Initial SvcParamKeys . . . . . . . . . . . . . . . . . . . . 16 104 6.1. "alpn" . . . . . . . . . . . . . . . . . . . . . . . . . 16 105 6.2. "port" . . . . . . . . . . . . . . . . . . . . . . . . . 17 106 6.3. "esniconfig" . . . . . . . . . . . . . . . . . . . . . . 17 107 6.4. "ipv4hint" and "ipv6hint" . . . . . . . . . . . . . . . . 17 108 7. Using SVCB with HTTPS and HTTP . . . . . . . . . . . . . . . 18 109 7.1. Owner names for HTTPSSVC records . . . . . . . . . . . . 19 110 7.2. Populating Alt-Used . . . . . . . . . . . . . . . . . . . 19 111 7.3. Differences from Alt-Svc . . . . . . . . . . . . . . . . 19 112 7.3.1. Untrusted channel . . . . . . . . . . . . . . . . . . 19 113 7.3.2. Caching and granularity . . . . . . . . . . . . . . . 20 114 7.4. HTTP Strict Transport Security . . . . . . . . . . . . . 20 115 8. Alt-Svc and SVCB/HTTPSSVC parameter for ESNI keys . . . . . . 21 116 8.1. Handling a mixture of alternatives not supporting ESNI . 21 117 9. Interaction with other standards . . . . . . . . . . . . . . 22 118 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 119 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 120 11.1. New registry for Service Parameters . . . . . . . . . . 22 121 11.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . 23 122 11.1.2. Initial contents . . . . . . . . . . . . . . . . . . 23 123 11.2. Registry updates . . . . . . . . . . . . . . . . . . . . 24 124 12. Acknowledgments and Related Proposals . . . . . . . . . . . . 25 125 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 126 13.1. Normative References . . . . . . . . . . . . . . . . . . 25 127 13.2. Informative References . . . . . . . . . . . . . . . . . 28 128 Appendix A. Mapping between HTTPSSVC and Alt-Svc . . . . . . . . 29 129 A.1. Multiple records and preference ordering . . . . . . . . 30 130 A.2. Additional examples . . . . . . . . . . . . . . . . . . . 30 131 Appendix B. Comparison with alternatives . . . . . . . . . . . . 31 132 B.1. Differences from the SRV RR type . . . . . . . . . . . . 31 133 B.2. Differences from the proposed HTTP record . . . . . . . . 31 134 B.3. Differences from the proposed ANAME record . . . . . . . 32 135 B.4. Differences from the proposed ESNI record . . . . . . . . 32 136 B.5. SNI Alt-Svc parameter . . . . . . . . . . . . . . . . . . 32 137 Appendix C. Design Considerations and Open Issues . . . . . . . 32 138 C.1. Record Name . . . . . . . . . . . . . . . . . . . . . . . 33 139 C.2. Generality . . . . . . . . . . . . . . . . . . . . . . . 33 140 C.3. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 33 141 C.4. Where to include Priority . . . . . . . . . . . . . . . . 33 142 C.5. Whether to include Weight . . . . . . . . . . . . . . . . 33 143 Appendix D. Change history . . . . . . . . . . . . . . . . . . . 33 144 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 146 1. Introduction 148 The SVCB and HTTPSSVC RRs provide clients with complete instructions 149 for access to an origin. This information enables improved 150 performance and privacy by avoiding transient connections to a sub- 151 optimal default server, negotiating a preferred protocol, and 152 providing relevant public keys. 154 For example, when clients need to make a connection to fetch 155 resources associated with an HTTPS URI, they currently resolve only A 156 and/or AAAA records for the origin hostname. This is adequate for 157 services that use basic HTTPS (fixed port, no QUIC, no [ESNI]). 158 Going beyond basic HTTPS confers privacy, performance, and 159 operational advantages, but it requires the client to learn 160 additional information, and it is highly desirable to minimize the 161 number of round-trip and lookups required to learn this additional 162 information. 164 The SVCB and HTTPSSVC RRs also help when the operator of an origin 165 wishes to delegate operational control to one or more other domains, 166 e.g. delegating the origin resource "https://example.com" to a 167 service operator endpoint at "svc.example.net". While this case can 168 sometimes be handled by a CNAME, that does not cover all use-cases. 169 CNAME is also inadequate when the service operator needs to provide a 170 bound collection of consistent configuration parameters through the 171 DNS (such as network location, protocol, and keying information). 173 This document first describes the SVCB RR as a general-purpose 174 resource record that can be applied directly and efficiently to a 175 wide range of services. As HTTPS is a primary use-case and has 176 special requirements, the HTTPSSVC RR is also defined within this 177 document as a special case of SVCB. Services wishing to avoid the 178 need for an [Attrleaf] label with SVCB may follow the pattern of 179 HTTPSSVC and assign their own SVCB-compatible RR types. 181 All behaviors described as applying to the SVCB RR also apply to the 182 HTTPSSVC RR unless explicitly stated otherwise. Section 7 describes 183 additional behaviors specific to the HTTPSSVC record. Apart from 184 Section 7 and introductory examples, much of this document refers 185 only to the SVCB RR, but those references should be taken to apply to 186 SVCB, HTTPSSVC, and any future SVCB-compatible RR types. 188 The SVCB RR has two forms: 1) the "Alias Form" simply delegates 189 operational control for a resource; 2) the "Service Form" binds 190 together configuration information for a service endpoint. The 191 Service Form provides additional key=value parameters within each 192 RDATA set. 194 TO BE REMOVED: If we use this for providing configuration for DNS 195 authorities, it is likely we'd specify a distinct "NS2" RR type that 196 is an instantiation of SVCB for authoritative nameserver delegation 197 and parameter specification, similar to HTTPSSVC. 199 TO BE REMOVED: Another open question is whether SVCB records should 200 be self-descriptive and include the service name (eg, "https") in the 201 RDATA section to avoid ambiguity. Perhaps this could be included as 202 a svc="baz" parameter for protocols that are not the default for the 203 RR type? Current inclination is to not do so. 205 1.1. Introductory Example 207 As an introductory example for an HTTPS origin resource, a set of 208 example HTTPSSVC and associated A+AAAA records might be: 210 www.example.com. 7200 IN CNAME svc.example.net. 211 ; AliasForm 212 example.com. 7200 IN HTTPSSVC 0 svc.example.net. 213 ; ServiceForm 214 svc.example.net. 7200 IN HTTPSSVC 2 svc3.example.net. ( alpn=h3 215 port=8003 esniconfig="..." ) 216 svc.example.net. 7200 IN HTTPSSVC 3 svc2.example.net. ( alpn=h2 217 port=8002 esniconfig="..." ) 218 svc2.example.net. 300 IN A 192.0.2.2 219 svc2.example.net. 300 IN AAAA 2001:db8::2 220 svc3.example.net. 300 IN A 192.0.2.3 221 svc3.example.net. 300 IN AAAA 2001:db8::3 222 ; Compatibility records for non-HTTPSSVC-aware clients 223 example.com. 300 IN A 192.0.2.1 224 example.com. 300 IN AAAA 2001:db8::1 225 svc.example.net. 300 IN A 192.0.2.1 226 svc.example.net. 300 IN AAAA 2001:db8::1 228 In the preceding example, both of the "example.com" and 229 "www.example.com" origin names are aliased to use alternative service 230 endpoints offered as "svc.example.net" (with "www.example.com" 231 continuing to use a CNAME alias). HTTP/2 is available on a cluster 232 of machines located at svc2.example.net with TCP port 8002 and HTTP/3 233 is available on a cluster of machines located at svc3.example.net 234 with UDP port 8003. The client can use the specified ESNI keys to 235 encrypt the SNI values of "example.com" and "www.example.com" in the 236 handshake with these alternative service endpoints. When connecting, 237 clients will continue to treat the authoritative origins as 238 "https://example.com" and "https://www.example.com", respectively. 240 For services other than HTTPS (as well as for HTTPS origins with non- 241 default ports), the SVCB RR and an [Attrleaf] label will be used. 243 For example, to reach an example resource of 244 "baz://api.example.com:8765", the following Alias Form SVCB record 245 would be used to delegate to "svc4-baz.example.net." which in-turn 246 could return AAAA/A records and/or SVCB records in ServiceForm. 248 _8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net. 250 1.2. Goals of the SVCB RR 252 The goal of the SVCB RR is to allow clients to resolve a single 253 additional DNS RR in a way that: 255 o Provides service endpoints authoritative for the service, along 256 with parameters associated with each of these endpoints. 258 o Does not assume that all alternative service endpoints have the 259 same parameters or capabilities, or are even operated by the same 260 entity. This is important as DNS does not provide any way to tie 261 together multiple RRs for the same name. For example, if 262 www.example.com is a CNAME alias that switches between one of 263 three CDNs or hosting environments, successive queries for that 264 name may return records that correspond to different environments. 266 o Enables CNAME-like functionality at a zone apex (such as 267 "example.com") for participating protocols, and generally enables 268 delegation of operational authority for an origin within the DNS 269 to an alternate name. 271 Additional goals specific to HTTPSSVC and the HTTPS use-case include: 273 o Connect directly to [HTTP3] (QUIC transport) alternative service 274 endpoints 276 o Obtain the [ESNI] keys associated with an alternative service 277 endpoint 279 o Support non-default TCP and UDP ports 281 o Address a set of long-standing issues due to HTTP(S) clients not 282 implementing support for SRV records, as well as due to a 283 limitation that a DNS name can not have both CNAME and NS RRs (as 284 is the case for zone apex names) 286 o Provide an HSTS-like indication signaling for the duration of the 287 DNS RR TTL that the HTTPS scheme should be used instead of HTTP 288 (see Section 7.4). 290 1.3. Overview of the SVCB RR 292 This subsection briefly describes the SVCB RR in a non-normative 293 manner. (As mentioned above, this all applies equally to the 294 HTTPSSVC RR which shares the same encoding, format, and high-level 295 semantics.) 297 The SVCB RR has two forms: AliasForm and ServiceForm. SVCB RR 298 entries with two non-empty fields are in AliasForm. When more fields 299 are present, this indicates that the SVCB RR is in ServiceForm. The 300 fields are: 302 1. SvcFieldPriority: The priority of this record (relative to 303 others, with lower values preferred). Applicable for the 304 ServiceForm, and otherwise has value "0". (Described in 305 Appendix A.1.) 307 2. SvcDomainName: The domain name of either the alias target (for 308 AliasForm) or the alternative service endpoint (for ServiceForm). 310 3. SvcFieldValue: A list of key=value pairs describing the 311 alternative service endpoint for the domain name specified in 312 SvcDomainName (only for ServiceForm and otherwise empty). 313 Described in Section 2.1. 315 Cooperating DNS recursive resolvers will perform subsequent record 316 resolution (for SVCB, A, and AAAA records) and return them in the 317 Additional Section of the response. Clients must either use 318 responses included in the additional section returned by the 319 recursive resolver or perform necessary SVCB, A, and AAAA record 320 resolutions. DNS authoritative servers may attach in-bailiwick SVCB, 321 A, AAAA, and CNAME records in the Additional Section to responses for 322 an SVCB query. 324 When in the ServiceForm, the SvcFieldValue of the SVCB RR provides an 325 extensible data model for describing network endpoints that are 326 authoritative for the origin, along with parameters associated with 327 each of these endpoints. 329 For the HTTPS use-case, the HTTPSSVC RR enables many of the benefits 330 of [AltSvc], without waiting for a full HTTP connection initiation 331 (multiple roundtrips) before learning of the preferred alternative, 332 and without necessarily revealing the user's intended destination to 333 all entities along the network path. 335 1.4. Parameter for ESNI 337 This document also defines a parameter for Encrypted SNI [ESNI] keys, 338 both as a general SVCB parameter and also as a corresponding Alt-Svc 339 parameter. See Section 8. 341 1.5. Terminology 343 For consistency with [AltSvc], we adopt the following definitions: 345 o An "origin" is an information source as in [RFC6454]. For 346 services other than HTTPS, the exact definition will need to be 347 provided by the document mapping that service onto the SVCB RR. 349 o The "origin server" is the server that the client would reach when 350 accessing the origin in the absence of the SVCB record or an HTTPS 351 Alt-Svc. 353 o An "alternative service" is a different server that can serve the 354 origin over a specified protocol. 356 For example within HTTPS, the origin consists of a scheme (typically 357 "https"), a host name, and a port (typically "443"). 359 Additional DNS terminology intends to be consistent with [DNSTerm]. 361 SVCB is a contraction of "service binding". HTTPSSVC is a 362 contraction of "HTTPS service". SVCB, HTTPSSVC, and future RR types 363 that share SVCB's format and registry are collectively known as SVCB- 364 compatible RR types. 366 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 367 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 368 "OPTIONAL" in this document are to be interpreted as described in BCP 369 14 [RFC2119] [RFC8174] when, and only when, they appear in all 370 capitals, as shown here. 372 2. The SVCB record type 374 The SVCB DNS resource record (RR) type (RR type ???) is used to 375 locate endpoints that can service an origin. There is special 376 handling for the case of "https" origins. The presentation format of 377 the record is: 379 Name TTL IN SVCB SvcFieldPriority SvcDomainName SvcFieldValue 381 The SVCB record is defined specifically within the Internet ("IN") 382 Class ([RFC1035]). SvcFieldPriority is a number in the range 383 0-65535, SvcDomainName is a domain name, and SvcFieldValue is a set 384 of key=value pairs present for the ServiceForm. The SvcFieldValue is 385 empty for the AliasForm. 387 The algorithm for resolving SVCB records and associated address 388 records is specified in Section 3. 390 2.1. Parameter specification via ServiceFieldValue 392 In ServiceForm, the SvcFieldValue contains key=value pairs. Keys are 393 IANA-registered SvcParamKeys (Section 11.1) with both a case- 394 insensitive string representation and a numeric representation in the 395 range 0-65535. Registered key names should only contain characters 396 from the ranges "a"-"z", "0"-"9", and "-". In ABNF [RFC5234], 398 ALPHA_LC = %x61-7A ; a-z 399 key = ALPHA_LC / DIGIT / "-" 400 display-key = ALPHA / DIGIT / "-" 402 Values are in a format specific to the SvcParamKey. Their definition 403 should specify both their presentation format and wire encoding 404 (e.g., domain names, binary data, or numeric values). 406 The SVCB format preserves the order of values and can encode multiple 407 values for the same parameter. However, clients MUST consider only 408 the first appearance of a parameter unless its specification 409 explicitly allows multiple values. 411 2.1.1. Presentation format 413 The presentation format for SvcFieldValue is a whitespace-separated 414 list of the key=value pairs. Each pair is presented in the following 415 form: 417 ; basic-visible is VCHAR minus DQUOTE, ";", and "\" 418 basic-visible = %x21 / %x23-3A / %x3C-5B / %x5D-7E 419 escaped-char = "\" (VCHAR / WSP) 420 contiguous = *(basic-visible / escaped-char) 421 quoted-string = DQUOTE *(contiguous / WSP) DQUOTE 422 value = quoted-string / contiguous 423 pair = display-key "=" value 425 The value format is intended to match the definition of in [RFC1035] Section 5.1. (Unlike , the 427 length of a value is not limited to 255 characters.) 429 Unrecognized keys are represented in presentation format as 430 "keyNNNNN" where NNNNN is the numeric value of the key type without 431 leading zeros. In presentation format, values of unrecognized keys 432 should be represented in wire format, using decimal escape codes 433 (e.g. \255) when necessary. 435 2.2. SVCB RDATA Wire Format 437 The RDATA for the SVCB RR consists of: 439 o a 2 octet field for SvcFieldPriority as an integer in network byte 440 order. 442 o the uncompressed SvcDomainName, represented as a sequence of 443 length-prefixed labels as in Section 3.1 of [RFC1035]. 445 o the SvcFieldValue byte string, consuming the remainder of the 446 record (so smaller than 65535 octets and constrained by the RDATA 447 and DNS message sizes). 449 AliasForm is defined by SvcFieldPriority being 0. 451 When SvcFieldValue is non-empty (ServiceForm), it contains a list of 452 SvcParamKey=SvcParamValue pairs with length-prefixes for the 453 SvcParamValues, each of which contains: 455 o a 2 octet field containing the SvcParamKey as an integer in 456 network byte order. 458 o a 2 octet field containing the length of the SvcParamValue as an 459 integer between 0 and 65535 in network byte order (but constrained 460 by the RDATA and DNS message sizes). 462 o an octet string of the length defined by the previous field. 464 If the parser reaches the end of the RDATA while parsing a 465 SvcFieldValue, the RR is invalid and MUST be discarded. 467 TODO: decide if we want special handling for any SvcParamKey ranges? 468 For example: range for greasing; experimental range; range-of- 469 mandatory-to-use-the-RR vs range of ignore-just-param-if-unknown. 471 2.3. SVCB owner names 473 When querying the SVCB RR, an origin is typically translated into a 474 QNAME by prefixing the port and scheme with "_", then concatenating 475 them with the host name, resulting in a domain name like 476 "_8004._examplescheme.api.example.com.". 478 Protocol mappings for SVCB MAY remove the port or replace it with 479 other protocol-specific information, but MUST retain the scheme in 480 the QNAME. RR types other than SVCB can define additional behavior 481 for translating origins to QNAMEs. See Section 7.1 for the HTTPSSVC 482 behavior. 484 When a prior CNAME or SVCB record has aliased to an SVCB record, each 485 RR shall be returned under its own owner name. 487 Note that none of these forms alter the origin or authority for 488 validation purposes. For example, clients MUST continue to validate 489 TLS certificate hostnames based on the origin host. 491 As an example: 493 _8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net. 494 svc4.example.net. 7200 IN SVCB 3 ( svc4.example.net. alpn="bar" 495 port="8004" esniconfig="..." ) 497 would indicate that "foo://api.example.com:8443" is aliased to use 498 ALPN protocol "bar" service endpoints offered at "svc4.example.net" 499 on port 8004. 501 2.4. SvcRecordType 503 The SvcRecordType is indicated by the SvcFieldPriority, and defines 504 the form of the SVCB RR. When SvcFieldPriority is 0, the SVCB 505 SvcRecordType is defined to be in AliasForm. Otherwise, the SVCB 506 SvcRecordType is defined to be in ServiceForm. 508 Within an SVCB RRSet, all RRs should have the same SvcRecordType. If 509 an RRSet contains a record in AliasForm, the client MUST ignore any 510 records in the set with ServiceForm. 512 2.5. SVCB records: AliasForm 514 When SvcRecordType is AliasForm, the SVCB record is to be treated 515 similar to a CNAME alias pointing to SvcDomainName. SVCB RRSets 516 SHOULD only have a single resource record in this form. If multiple 517 are present, clients or recursive resolvers SHOULD pick one at 518 random. 520 The AliasForm's primary purpose is to allow aliasing at the zone 521 apex, where CNAME is not allowed. For example, if an operator of 522 https://example.com wanted to point HTTPS requests to a service 523 operating at svc.example.net, they would publish a record such as: 525 example.com. 3600 IN SVCB 0 svc.example.net. 527 The SvcDomainName MUST point to a domain name that contains another 528 SVCB record, address (AAAA and/or A) records, or both address records 529 and a ServiceForm SVCB record. 531 Note that the SVCB record's owner name MAY be the canonical name of a 532 CNAME record, and the SvcDomainName MAY be the owner of a CNAME 533 record. Clients and recursive resolvers MUST follow CNAMEs as 534 normal. 536 Due to the risk of loops, clients and recursive resolvers MUST 537 implement loop detection. Chains of consecutive SVCB and CNAME 538 records SHOULD be limited to (8?) prior to reaching terminal address 539 records. 541 As legacy clients will not know to use this record, service operators 542 will likely need to retain fallback AAAA and A records alongside this 543 SVCB record, although in a common case the target of the SVCB record 544 might offer better performance, and therefore would be preferable for 545 clients implementing this specification to use. 547 Note that SVCB AliasForm RRs do not alias to RR types other than 548 address records (AAAA and A), CNAMEs, and ServiceForm SVCB records. 549 For example, an AliasForm SVCB record does not alias to an HTTPSSVC 550 record, nor vice-versa. 552 2.6. SVCB records: ServiceForm 554 When SvcRecordType is the ServiceForm, the combination of 555 SvcDomainName and SvcFieldValue parameters within each resource 556 record associates an alternative service location with its connection 557 parameters. 559 Each protocol scheme that uses SVCB MUST define a protocol mapping 560 that explains how SvcFieldValues are applied for connections of that 561 scheme. Appendix A defines a limited mapping between Alt-Svc 562 ([AltSvc]) values and the SVCB ServiceForm. Protocols using SVCB may 563 use this Alt-Svc mapping if they also use Alt-Svc. Unless specified 564 otherwise by the protocol mapping, clients MUST ignore SvcFieldValue 565 parameters that they do not recognize. 567 2.6.1. Special handling of "." for SvcDomainName in ServiceForm 569 For ServiceForm SVCB RRs, if SvcDomainName has the value ".", then 570 the owner name of this record MUST be used as the effective 571 SvcDomainName. (The SvcDomainName of an SVCB RR in AliasForm MUST 572 NOT have this value.) 573 For example, in the following example "svc2.example.net" is the 574 effective SvcDomainName: 576 www.example.com. 7200 IN HTTPSSVC svc.example.net. 577 svc.example.net. 7200 IN CNAME svc2.example.net. 578 svc2.example.net. 7200 IN HTTPSSVC 1 . ( alpn=h2 579 port=8002 esniconfig="..." ) 580 svc2.example.net. 300 IN A 192.0.2.2 581 svc2.example.net. 300 IN AAAA 2001:db8::2 583 2.6.2. SvcFieldPriority 585 As RRs within an RRSet are explicitly unordered collections, the 586 SvcFieldPriority value serves to indicate priority. SVCB RRs with a 587 smaller SvcFieldPriority value SHOULD be given preference over RRs 588 with a larger SvcFieldPriority value. 590 When receiving an RRSet containing multiple SVCB records with the 591 same SvcFieldPriority value, clients SHOULD apply a random shuffle 592 within a priority level to the records before using them, to ensure 593 uniform load-balancing. 595 3. Client behavior 597 An SVCB-aware client resolves an origin HOST by attempting to 598 determine the preferred SvcFieldValue and IP addresses for its 599 service, using the following procedure: 601 1. Issue parallel AAAA/A and SVCB queries for the name HOST. The 602 answers for these may or may not include CNAME pointers before 603 reaching one or more of these records. 605 2. If an SVCB record of AliasForm SvcRecordType is returned for 606 HOST, clients MUST loop back to step 1 replacing HOST with 607 SvcDomainName, subject to loop detection heuristics. 609 3. If one or more SVCB records of ServiceForm SvcRecordType are 610 returned for HOST, clients should select the highest-priority 611 option with acceptable parameters, and resolve AAAA and/or A 612 records for its SvcDomainName if they are not already available. 613 These are the preferred SvcFieldValue and IP addresses. If the 614 connection fails, the client MAY try to connect using values from 615 a lower-priority record. If none of the options succeed, the 616 client SHOULD connect to the origin server directly. 618 4. If an SVCB record for HOST does not exist, the received AAAA and/ 619 or A records are the preferred IP addresses and there is no 620 SvcFieldValue. 622 This procedure does not rely on any recursive or authoritative server 623 to comply with this specification or have any awareness of SVCB. 625 When selecting between AAAA and A records to use, clients may use an 626 approach such as [HappyEyeballsV2]. 628 Some important optimizations are discussed in Section 5 to avoid 629 additional latency in comparison to ordinary AAAA/A lookups. 631 3.1. Clients using a Proxy 633 Clients using a domain-oriented transport proxy like HTTP CONNECT 634 ([RFC7231] Section 4.3.6) or SOCKS5 ([RFC1928]) SHOULD disable SVCB 635 support if performing SVCB queries would violate the client's privacy 636 intent. 638 If the client can safely perform SVCB queries (e.g. via the proxy or 639 an affiliated resolver), the client SHOULD follow the standard SVCB 640 resolution process, selecting the highest priority option that is 641 compatible with the client and the proxy. The client SHOULD provide 642 the final SvcDomainName and port (if present) to the proxy as the 643 destination host and port. 645 Providing the proxy with the final SvcDomainName has several 646 benefits: 648 o It allows the client to use the SvcFieldValue, if present, which 649 is only usable with a specific SvcDomainName. The SvcFieldValue 650 may include information that enhances performance (e.g. alpn) and 651 privacy (e.g. esniconfig). 653 o It allows the origin to delegate the apex domain. 655 o It allows the proxy to select between IPv4 and IPv6 addresses for 656 the server according to its configuration, and receive addresses 657 based on its network geolocation. 659 4. DNS Server Behavior 661 When replying to an SVCB query, authoritative DNS servers SHOULD 662 return A, AAAA, and SVCB records (as well as any relevant CNAME 663 records) in the Additional Section for any in-bailiwick 664 SvcDomainNames. 666 Recursive resolvers that are aware of SVCB SHOULD ensure that the 667 client can execute the procedure in Section 3 without issuing a 668 second round of queries, by following this procedure while 669 constructing a response to a stub resolver for an SVCB record query: 671 1. When processing an SVCB response from an authoritative server, 672 add it to the Additional section (unless it is the Answer). 674 2. If all records are in ServiceForm, resolve A and AAAA records for 675 each SvcDomainName (or for the owner name if the SvcDomainName is 676 "."), and include all the results in the Additional section. 678 3. Otherwise, select an AliasForm record at random, and resolve A, 679 AAAA, and SVCB records for the SvcDomainName. If the SVCB record 680 does not exist, add the A and AAAA records to the Additional 681 section. Otherwise, go to step 1, subject to loop detection 682 heuristics. 684 All DNS servers SHOULD treat the SvcParam portion of the SVCB RR as 685 opaque and SHOULD NOT try to alter their behavior based on its 686 contents. 688 When responding to a query that includes the DNSSEC OK bit 689 ([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers 690 MUST accompany each RRSet in the Additional section with the same 691 DNSSEC-related records that it would send when providing that RRSet 692 as an Answer. 694 5. Performance optimizations 696 For optimal performance (i.e. minimum connection setup time), clients 697 SHOULD issue address (AAAA and/or A) and SVCB queries simultaneously, 698 and SHOULD implement a client-side DNS cache. Responses in the 699 Additional section of an SVCB response SHOULD be placed in cache 700 before performing any followup queries. With these optimizations in 701 place, and conforming DNS servers, using SVCB does not add network 702 latency to connection setup. 704 5.1. Optimistic pre-connection and connection reuse 706 If an address response arrives before the corresponding SVCB 707 response, the client MAY initiate a connection as if the SVCB query 708 returned NODATA, but MUST NOT transmit any information that could be 709 altered by the SVCB response until it arrives. For example, a TLS 710 ClientHello can be altered by the "esniconfig" value of an SVCB 711 response (Section 6.3). Clients implementing this optimization 712 SHOULD wait for 50 milliseconds before starting optimistic pre- 713 connection, as per the guidance in [HappyEyeballsV2]. 715 An SVCB record is consistent with a connection if the client would 716 attempt an equivalent connection when making use of that record. If 717 an SVCB record is consistent with an active or in-progress connection 718 C, the client MAY prefer that record and use C as its connection. 720 For example, suppose the client receives this SVCB RRSet for a 721 protocol that uses TLS over TCP: 723 _1234._bar.example.com. 300 IN SVCB 1 svc1.example.net ( 724 esniconfig="111..." ipv6hint=2001:db8::1 port=1234 ... ) 725 SVCB 2 svc2.example.net ( 726 esniconfig="222..." ipv6hint=2001:db8::2 port=1234 ... ) 728 If the client has an in-progress TCP connection to 729 "[2001:db8::2]:1234", it MAY proceed with TLS on that connection 730 using "esniconfig="222..."", even though the other record in the 731 RRSet has higher priority. 733 If none of the SVCB records are consistent with any active or in- 734 progress connection, clients must proceed as described in Step 3 of 735 the procedure in Section 3. 737 5.2. Preferring usable records 739 A nonconforming recursive resolver might not return all the 740 information required to use all the records in an SVCB response. If 741 some of the SVCB records in the response can be used without 742 requiring additional DNS queries, the client MAY prefer those 743 records, regardless of their priorities. 745 5.3. Structuring zones for performance 747 To avoid a delay for clients using a nonconforming recursive 748 resolver, domain owners SHOULD use a single SVCB record whose 749 SvcDomainName is in the origin hostname's CNAME chain if possible. 750 This will ensure that the required address records are already 751 present in the client's DNS cache as part of the responses to the 752 address queries that were issued in parallel. 754 6. Initial SvcParamKeys 756 A few initial SvcParamKeys are defined here. These keys are useful 757 for HTTPS, and most are applicable to other protocols as well. 759 6.1. "alpn" 761 The "alpn" SvcParamKey defines the Application Layer Protocol (ALPN, 762 as defined in {{!RFC7301}) supported by a TLS-based alternative 763 service. Its value SHOULD be an entry in the IANA registry "TLS 764 Application-Layer Protocol Negotiation (ALPN) Protocol IDs". 766 The presentation format and wire format of SvcParamValue is its 767 registered "Identification Sequence". 769 Clients MUST ignore SVCB RRs where the "alpn" SvcParamValue is 770 unknown or unsupported. 772 6.2. "port" 774 The "port" SvcParamKey defines the TCP or UDP port that should be 775 used to contact this alternative service. 777 The presentation format of the SvcParamValue is a numeric value 778 between 0 and 65535 inclusive. The wire format of the SvcParamValue 779 is the corresponding 2 octet numeric value in network byte order. 781 6.3. "esniconfig" 783 The SvcParamKey for ESNI is "esniconfig". Its value is defined in 784 Section 8. It is applicable to most TLS-based protocols. 786 When publishing a record containing an "esniconfig" parameter, the 787 publisher MUST ensure that all IP addresses of SvcDomainName 788 correspond to servers that have access to the corresponding private 789 key or are authoritative for the fallback domain. (See [ESNI] for 790 more details about the fallback domain.) This yields an anonymity 791 set of cardinality equal to the number of ESNI-enabled server domains 792 supported by a given client-facing server. Thus, even with SNI 793 encryption, an attacker who can enumerate the set of ESNI-enabled 794 domains supported by a client-facing server can guess the correct SNI 795 with probability at least 1/K, where K is the size of this ESNI- 796 enabled server anonymity set. This probability may be increased via 797 traffic analysis or other mechanisms. 799 6.4. "ipv4hint" and "ipv6hint" 801 The "ipv4hint" and "ipv6hint" keys represent IP address hints for the 802 service. If A and AAAA records for SvcDomainName are locally 803 available, the client SHOULD ignore these hints. Otherwise, clients 804 SHOULD perform A and/or AAAA queries for SvcDomainName as in 805 Section 3, and clients SHOULD use the IP address in those responses 806 for future connections. Clients MAY opt to terminate any connections 807 using the addresses in hints and instead switch to the addresses in 808 response to the SvcDomainName. Failure to use A and/or AAAA response 809 addresses may negatively impact load balancing or other geo-aware 810 features and thereby degrade client performance. 812 The wire format for each parameter is a sequence of IP addresses in 813 network byte order. Like an A or AAAA RRSet, the list of addresses 814 represents an unordered collection, and clients SHOULD pick addresses 815 to use in a random order. 817 These parameters MAY be repeated multiple times within a record. 818 When receiving such a record, clients SHOULD combine the sets of 819 addresses. 821 When selecting between IPv4 and IPv6 addresses to use, clients may 822 use an approach such as [HappyEyeballsV2]. When only "ipv4hint" 823 parameters are present, IPv6-only clients may synthesize IPv6 824 addresses as specified in [RFC7050] or ignore the "ipv4hint" key and 825 wait for AAAA resolution (Section 3). Recursive resolvers MUST NOT 826 perform DNS64 ([RFC6147]) on parameters within an SVCB record. For 827 best performance, server operators SHOULD include "ipv6hint" 828 parameters whenever they publish "ipv4hint" parameters. 830 The presentation format for each parameter is a comma-separated list 831 of IP addresses in standard textual format [RFC5952]. 833 These parameters are intended to minimize additional connection 834 latency when a recursive resolver is not compliant with the 835 requirements in Section 4, and SHOULD NOT be included if most clients 836 are using compliant recursive resolvers. 838 7. Using SVCB with HTTPS and HTTP 840 Use of any protocol with SVCB requires a protocol-specific mapping 841 specification. This section specifies the mapping for HTTPS and 842 HTTP. 844 To enable special handling for the HTTPS and HTTP use-cases, the 845 HTTPSSVC RR type is defined as an SVCB-compatible RR type, specific 846 to the https and http schemes. Clients MUST NOT perform SVCB queries 847 or accept SVCB responses for https or http schemes. 849 The HTTPSSVC wire format and presentation format are identical to 850 SVCB, and both share the SvcParamKey registry. SVCB semantics apply 851 equally to HTTPSSVC unless specified otherwise. 853 The presence of an HTTPSSVC record for an HTTP or HTTPS service also 854 provides an indication that all resources are available over HTTPS, 855 as discussed in Section 7.4. This allows HTTPSSVC RRs to apply to 856 pre-existing HTTP scheme URLs, while ensuring that the client uses a 857 secure and authenticated HTTPS connection. 859 The HTTPSSVC RR parallels the concepts introduced in the HTTP 860 Alternative Services proposed standard [AltSvc]. Clients and servers 861 that implement HTTPSSVC are NOT REQUIRED to implement Alt-Svc. 862 However, many clients and servers will implement both, and a partial 863 mapping exists between them (Appendix A). 865 7.1. Owner names for HTTPSSVC records 867 The HTTPSSVC RR extends the behavior for determining a QNAME 868 specified above in Section 2.3. In particular, if the scheme is 869 "https" with port 443, or the scheme is "http" and the port is 80, 870 then the client's original QNAME is equal to the origin host name. 872 For origins other than https with port 443 and http with port 80, the 873 port and scheme continue to be prefixed to the hostname as described 874 in Section 2.3. Following of HTTPSSVC AliasForm and CNAME aliases is 875 also unchanged from SVCB. 877 Note that none of these forms alter the HTTPS origin or authority. 878 For example, clients MUST continue to validate TLS certificate 879 hostnames based on the origin host. 881 7.2. Populating Alt-Used 883 When using an HTTPSSVC RR in ServiceForm, all clients SHOULD include 884 the "Alt-Used" HTTP header (Section 5 of [RFC7838]). The header's 885 value (in ABNF) SHOULD be 887 uri-host ":" port 889 where uri-host is the final value of HOST ({client-behavior}) minus 890 the trailing ".", and port is the port number in use. 892 7.3. Differences from Alt-Svc 894 Publishing a ServiceForm HTTPSSVC record in DNS is intended to be 895 similar to transmitting the corresponding Alt-Svc field value over 896 HTTPS, and receiving an HTTPSSVC record is intended to be similar to 897 receiving that field value over HTTPS. However, there are some 898 differences in the intended client and server behavior. 900 7.3.1. Untrusted channel 902 SVCB does not require or provide any assurance of authenticity. 903 (DNSSEC signing and verification, which would provide such assurance, 904 are OPTIONAL.) The DNS resolution process is treated as an untrusted 905 channel that learns only the QNAME, and is prevented from mounting 906 any attack beyond denial of service. 908 Alt-Svc parameters that cannot be safely received in this model MUST 909 NOT have a corresponding defined SvcParamKey. For example, there is 910 no SvcParamKey corresponding to the Alt-Svc "persist" parameter, 911 because this parameter is not safe to accept over an untrusted 912 channel. 914 7.3.2. Caching and granularity 916 There is no SvcParamKey corresponding to the Alt-Svc "ma" (max age) 917 parameter. Instead, server operators SHOULD encode the expiration 918 time in the DNS TTL. 920 Some DNS caching systems incorrectly extend the lifetime of DNS 921 records beyond the stated TTL. Server operators MUST NOT rely on 922 HTTPSSVC records expiring on time, and MAY shorten the TTL to 923 compensate. 925 Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc 926 Field Value specifically to the client. When using an HTTPSSVC DNS 927 record, groups of clients will necessarily receive the same Alt-Svc 928 Field Value. Therefore, HTTPSSVC is not suitable for uses that 929 require single-client granularity. 931 If the client has an Alt-Svc cache, and a usable Alt-Svc value is 932 present in that cache, then the client MAY skip the HTTPSSVC query. 934 If the client has a cached Alt-Svc entry that is expiring, the client 935 MAY perform an HTTPSSVC query to refresh the entry. 937 7.4. HTTP Strict Transport Security 939 By publishing an HTTPSSVC record, the server operator indicates that 940 all useful HTTP resources on that origin are reachable over HTTPS, 941 similar to HTTP Strict Transport Security [HSTS]. When an HTTPSSVC 942 record is present for an origin, all "http" scheme requests for that 943 origin SHOULD logically be redirected to "https". 945 Prior to making an "http" scheme request, the client SHOULD perform a 946 lookup to determine if an HTTPSSVC record is available for that 947 origin. To do so, the client SHOULD construct a corresponding 948 "https" URL as follows: 950 1. Replace the "http" scheme with "https". 952 2. If the "http" URL explicitly specifies port 80, specify port 443. 954 3. Do not alter any other aspect of the URL. 956 This construction is equivalent to Section 8.3 of [HSTS], point 5. 958 If an HTTPSSVC record is present for this "https" URL, the client 959 should treat this as the equivalent of receiving an HTTP "307 960 Temporary Redirect" redirect to the "https" URL. Because HTTPSSVC is 961 received over an often insecure channel (DNS), clients MUST NOT place 962 any more trust in this signal than if they had received a 307 963 redirect over cleartext HTTP. 965 If the HTTPSSVC query results in a SERVFAIL error, and the connection 966 between the client and the recursive resolver is cryptographically 967 protected (e.g. using TLS [RFC7858] or HTTPS [RFC8484]), the client 968 SHOULD abandon the connection attempt and display an error message. 969 A SERVFAIL error can occur if the domain is DNSSEC-signed, the 970 recursive resolver is DNSSEC-validating, and an active attacker 971 between the recursive resolver and the authoritative DNS server is 972 attempting to prevent the upgrade to HTTPS. 974 Similarly, if the client enforces DNSSEC validation on A/AAAA 975 responses, it SHOULD abandon the connection attempt if the HTTPSSVC 976 response fails to validate. 978 8. Alt-Svc and SVCB/HTTPSSVC parameter for ESNI keys 980 Both SVCB/HTTPSSVC and Alt-Svc "esniconfig" parameters are defined 981 for conveying the ESNI configuration of an alternative service. The 982 value of the parameter is an ESNIConfig structure [ESNI] or the empty 983 string. ESNI-aware clients SHOULD prefer alt-values and SVCB/ 984 HTTPSSVC RRs with non-empty esniconfig. 986 Both the SVCB SvcParamValue presentation format as well as the Alt- 987 Svc parameter value is the ESNIConfig structure [ESNI] encoded in 988 [base64] or the empty string. The SVCB SvcParamValue wire format is 989 the octet string containing the binary ESNIConfig structure. 991 This parameter MAY also be sent in Alt-Svc HTTP response headers and 992 HTTP/2 ALTSVC frames. This parameter MUST NOT appear more than once 993 in a single alt-value. 995 8.1. Handling a mixture of alternatives not supporting ESNI 997 The Alt-Svc specification states that "the client MAY fall back to 998 using the origin" in case of connection failure (Section 2.4 of 999 [AltSvc]). This behavior is not suitable for ESNI, because fallback 1000 would negate the privacy benefits of ESNI. 1002 Accordingly, any connection attempt that uses ESNI MUST fall back 1003 only to another alt-value that also has the esniconfig parameter. If 1004 the parameter's value is the empty string, the client SHOULD connect 1005 as it would in the absence of any ESNIConfig information. 1007 For example, suppose a server operator has two alternatives. 1008 Alternative A is reliably accessible but does not support ESNI. 1009 Alternative B supports ESNI but is not reliably accessible. The 1010 server operator could include a full esniconfig value in Alternative 1011 B, and mark Alternative A with esniconfig="" to indicate that 1012 fallback from B to A is allowed. 1014 Other clients and services implementing SVCB or HTTPSSVC with 1015 esniconfig are encouraged to take a similar approach. 1017 9. Interaction with other standards 1019 This standard is intended to reduce connection latency and improve 1020 user privacy. Server operators implementing this standard SHOULD 1021 also implement TLS 1.3 [RFC8446] and OCSP Stapling [RFC6066], both of 1022 which confer substantial performance and privacy benefits when used 1023 in combination with SVCB records. 1025 To realize the greatest privacy benefits, this proposal is intended 1026 for use over a privacy-preserving DNS transport (like DNS over TLS 1027 [RFC7858] or DNS over HTTPS [RFC8484]). However, performance 1028 improvements, and some modest privacy improvements, are possible 1029 without the use of those standards. 1031 Any specification for use of SVCB with a protocol MUST have an entry 1032 for its scheme under the SVCB RR type in the IANA DNS Underscore 1033 Global Scoped Entry Registry [Attrleaf]. The scheme SHOULD have an 1034 entry in the IANA URI Schemes Registry [RFC7595]. The scheme SHOULD 1035 have a defined specification for use with SVCB. 1037 10. Security Considerations 1039 SVCB/HTTPSSVC RRs are intended for distribution over untrusted 1040 channels, and clients are REQUIRED to verify that the alternative 1041 service is authoritative for the origin (Section 2.1 of [AltSvc]). 1042 Therefore, DNSSEC signing and validation are OPTIONAL for publishing 1043 and using SVCB and HTTPSSVC records. 1045 Clients MUST ensure that their DNS cache is partitioned for each 1046 local network, or flushed on network changes, to prevent a local 1047 adversary in one network from implanting a forged DNS record that 1048 allows them to track users or hinder their connections after they 1049 leave that network. 1051 11. IANA Considerations 1053 11.1. New registry for Service Parameters 1055 The "Service Binding (SVCB) Parameter Registry" defines the name 1056 space for parameters, including string representations and numeric 1057 SvcParamKey values. This registry is shared with other SVCB- 1058 compatible RR types, such as HTTPSSVC. 1060 ACTION: create and include a reference to this registry. 1062 11.1.1. Procedure 1064 A registration MUST include the following fields: 1066 o Name: Service parameter key name 1068 o SvcParamKey: Service parameter key numeric identifier (range 1069 0-65535) 1071 o Meaning: a short description 1073 o Pointer to specification text 1075 Values to be added to this name space require Expert Review (see 1076 [RFC5226], Section 4.1). Apart from the initial contents, the name 1077 MUST NOT start with "key". 1079 11.1.2. Initial contents 1081 The "Service Binding (SVCB) Parameter Registry" shall initially be 1082 populated with the registrations below: 1084 +-------------+------------+------------------------+---------------+ 1085 | SvcParamKey | NAME | Meaning | Reference | 1086 +-------------+------------+------------------------+---------------+ 1087 | 0 | key0 | Reserved | (This | 1088 | | | | document) | 1089 | | | | | 1090 | 1 | alpn | ALPN for alternative | (This | 1091 | | | service | document) | 1092 | | | | | 1093 | 2 | port | Port for alternative | (This | 1094 | | | service | document) | 1095 | | | | | 1096 | 3 | esniconfig | Encrypted SNI | (This | 1097 | | | configuration | document) | 1098 | | | | | 1099 | 4 | ipv4hint | IPv4 address hints | (This | 1100 | | | | document) | 1101 | | | | | 1102 | 5 | key5 | Reserved | (This | 1103 | | | | document) | 1104 | | | | | 1105 | 6 | ipv6hint | IPv6 address hints | (This | 1106 | | | | document) | 1107 | | | | | 1108 | 65280-65534 | keyNNNNN | Private Use | (This | 1109 | | | | document) | 1110 | | | | | 1111 | 65535 | key65535 | Reserved | (This | 1112 | | | | document) | 1113 +-------------+------------+------------------------+---------------+ 1115 TODO: do we also want to reserve a range for greasing? 1117 11.2. Registry updates 1119 Per [RFC6895], please add the following entry to the data type range 1120 of the Resource Record (RR) TYPEs registry: 1122 +----------+----------------------------------------+---------------+ 1123 | TYPE | Meaning | Reference | 1124 +----------+----------------------------------------+---------------+ 1125 | SVCB | Service Location and Parameter Binding | (This | 1126 | | | document) | 1127 | | | | 1128 | HTTPSSVC | HTTPS Service Location and Parameter | (This | 1129 | | Binding | document) | 1130 +----------+----------------------------------------+---------------+ 1131 Per [Attrleaf], please add the following entries to the DNS 1132 Underscore Global Scoped Entry Registry: 1134 +----------+------------+-------------------+-----------------+ 1135 | RR TYPE | _NODE NAME | Meaning | Reference | 1136 +----------+------------+-------------------+-----------------+ 1137 | HTTPSSVC | _https | Alt-Svc for HTTPS | (This document) | 1138 | | | | | 1139 | HTTPSSVC | _http | Alt-Svc for HTTPS | (This document) | 1140 +----------+------------+-------------------+-----------------+ 1142 Per [AltSvc], please add the following entry to the HTTP Alt-Svc 1143 Parameter Registry: 1145 +-------------------+-----------------------------+-----------------+ 1146 | Alt-Svc Parameter | Meaning | Reference | 1147 +-------------------+-----------------------------+-----------------+ 1148 | esniconfig | Encrypted SNI configuration | (This document) | 1149 +-------------------+-----------------------------+-----------------+ 1151 12. Acknowledgments and Related Proposals 1153 There have been a wide range of proposed solutions over the years to 1154 the "CNAME at the Zone Apex" challenge proposed. These include 1155 [I-D.draft-bellis-dnsop-http-record-00], 1156 [I-D.draft-ietf-dnsop-aname-03], and others. 1158 Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thompson, Lucas 1159 Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, and 1160 others for their feedback and suggestions on this draft. 1162 13. References 1164 13.1. Normative References 1166 [AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1167 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1168 April 2016, . 1170 [AltSvcSNI] 1171 Bishop, M., "The "SNI" Alt-Svc Parameter", draft-bishop- 1172 httpbis-sni-altsvc-02 (work in progress), May 2018. 1174 [Attrleaf] 1175 Crocker, D., "DNS Scoped Data Through "Underscore" Naming 1176 of Attribute Leaves", draft-ietf-dnsop-attrleaf-16 (work 1177 in progress), November 2018. 1179 [base64] Josefsson, S., "The Base16, Base32, and Base64 Data 1180 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1181 . 1183 [ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 1184 "Encrypted Server Name Indication for TLS 1.3", draft- 1185 ietf-tls-esni-04 (work in progress), July 2019. 1187 [HappyEyeballsV2] 1188 Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1189 Better Connectivity Using Concurrency", RFC 8305, 1190 DOI 10.17487/RFC8305, December 2017, 1191 . 1193 [HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1194 Transport Security (HSTS)", RFC 6797, 1195 DOI 10.17487/RFC6797, November 2012, 1196 . 1198 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 1199 (HTTP/3)", draft-ietf-quic-http-20 (work in progress), 1200 April 2019. 1202 [RFC1035] Mockapetris, P., "Domain names - implementation and 1203 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1204 November 1987, . 1206 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1207 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1208 DOI 10.17487/RFC1928, March 1996, 1209 . 1211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1212 Requirement Levels", BCP 14, RFC 2119, 1213 DOI 10.17487/RFC2119, March 1997, 1214 . 1216 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1217 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 1218 . 1220 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 1221 RFC 3225, DOI 10.17487/RFC3225, December 2001, 1222 . 1224 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 1225 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 1226 2003, . 1228 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1229 IANA Considerations Section in RFCs", RFC 5226, 1230 DOI 10.17487/RFC5226, May 2008, 1231 . 1233 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1234 Specifications: ABNF", STD 68, RFC 5234, 1235 DOI 10.17487/RFC5234, January 2008, 1236 . 1238 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1239 Address Text Representation", RFC 5952, 1240 DOI 10.17487/RFC5952, August 2010, 1241 . 1243 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1244 Extensions: Extension Definitions", RFC 6066, 1245 DOI 10.17487/RFC6066, January 2011, 1246 . 1248 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1249 Beijnum, "DNS64: DNS Extensions for Network Address 1250 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1251 DOI 10.17487/RFC6147, April 2011, 1252 . 1254 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1255 DOI 10.17487/RFC6454, December 2011, 1256 . 1258 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1259 the IPv6 Prefix Used for IPv6 Address Synthesis", 1260 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1261 . 1263 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1264 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1265 DOI 10.17487/RFC7231, June 2014, 1266 . 1268 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 1269 and Registration Procedures for URI Schemes", BCP 35, 1270 RFC 7595, DOI 10.17487/RFC7595, June 2015, 1271 . 1273 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1274 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1275 April 2016, . 1277 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1278 and P. Hoffman, "Specification for DNS over Transport 1279 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1280 2016, . 1282 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1283 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1284 May 2017, . 1286 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1287 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1288 . 1290 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1291 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1292 . 1294 13.2. Informative References 1296 [DNSTerm] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1297 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1298 January 2019, . 1300 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1301 Protocol (HTTP/1.1): Message Syntax and Routing", 1302 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1303 . 1305 [I-D.draft-bellis-dnsop-http-record-00] 1306 Bellis, R., "A DNS Resource Record for HTTP", draft- 1307 bellis-dnsop-http-record-00 (work in progress), November 1308 2018. 1310 [I-D.draft-ietf-dnsop-aname-03] 1311 Finch, T., Hunt, E., Dijk, P., Eden, A., and W. Mekking, 1312 "Address-specific DNS aliases (ANAME)", draft-ietf-dnsop- 1313 aname-03 (work in progress), April 2019. 1315 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1316 specifying the location of services (DNS SRV)", RFC 2782, 1317 DOI 10.17487/RFC2782, February 2000, 1318 . 1320 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 1321 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 1322 April 2013, . 1324 Appendix A. Mapping between HTTPSSVC and Alt-Svc 1326 Conversion between HTTPSSVC's ServiceForm and Alt-Svc is possible. 1327 Note that conversion in either direction can be lossy, because some 1328 parameters are only defined for HTTPSSVC or Alt-Svc. 1330 To construct an Alt-Svc Field Value (as defined in Section 4 of 1331 [AltSvc]) from an HTTPSSVC record: 1333 o The SvcDomainName is mapped into the uri-host portion of alt- 1334 authority with the trailing "." removed. (If SvcDomainName is 1335 ".", the special handling described in Section 2.6.1 MUST be 1336 applied first.) 1338 o The SvcParamValue of the "port" service parameter, or 443 if no 1339 such parameter is present, is written to the port portion of the 1340 alt-authority. 1342 o The SvcParamValue of the "alpn" service parameter is mapped to the 1343 protocol-id. This MUST follow the normalization and encoding 1344 requirements for protocol-id specified in [AltSvc] Section 3. 1345 This parameter is MANDATORY. 1347 o The DNS TTL is mapped to the "ma" (max age) Alt-Svc parameter. 1349 o For SVCB parameters with defined mappings to HTTPS Alt-Svc, each 1350 should be included as an Alt-Svc parameter, typically as the 1351 SvcParamKey name "=" a defined encoding of the SvcParamValue. 1353 Converting an Alt-Svc Field Value into an HTTPSSVC record follows the 1354 reverse of this procedure. 1356 Conversion between HTTPSSVC and Alt-Svc Field Value MUST ignore any 1357 SvcParamKeys and Alt-Svc parameters that are unrecognized or do not 1358 have a defined mapping. 1360 For example, if the operator of https://www.example.com intends to 1361 include an HTTP response header like 1363 Alt-Svc: h3="svc.example.net:8003"; ma=3600; foo=123, \ 1364 h2="svc.example.net:8002"; ma=3600; foo=123 1366 they could also publish an HTTPSSVC DNS RRSet like 1368 www.example.com. 3600 IN HTTPSSVC 2 svc.example.net. ( 1369 alpn=h3 port=8003 foo=123 ) 1370 HTTPSSVC 3 svc.example.net. ( 1371 alpn=h2 port=8002 foo=123 ) 1373 Where "foo" is a hypothetical future HTTPSSVC and Alt-Svc parameter. 1375 This data type can also be represented as an Unknown RR as described 1376 in [RFC3597]: 1378 www.example.com. 3600 IN TYPE??? \\# TBD:WRITEME 1380 A.1. Multiple records and preference ordering 1382 Server operators MAY publish multiple ServiceForm HTTPSSVC records as 1383 an RRSet. When converting a collection of alt-values into an 1384 HTTPSSVC RRSet, the server operator MUST set the overall TTL to a 1385 value no larger than the minimum of the "max age" values (following 1386 Section 5.2 of [RFC2181]). 1388 Each RR corresponds to exactly one alt-value, as described in 1389 Section 3 of [AltSvc]. 1391 As discussed in Section 2.6.2, HTTPSSVC RRs with a smaller 1392 SvcFieldPriority value SHOULD be sorted ahead of and given preference 1393 over RRs with a larger SvcFieldPriority value. 1395 When constructing equivalent Alt-Svc headers from an RRSet: 1397 1. The RRs SHOULD be ordered by increasing SvcFieldPriority, with 1398 shuffling for equal SvcFieldPriority values. Clients MAY choose 1399 to further prioritize alt-values where address records are 1400 immediately available for the alt-value's SvcDomainName. 1402 2. The client SHOULD concatenate the thus-transformed-and-ordered 1403 SvcFieldValues in the RRSet, separated by commas. (This is 1404 semantically equivalent to receiving multiple Alt-Svc HTTP 1405 response headers, according to Section 3.2.2 of [HTTP]). 1407 A.2. Additional examples 1409 The following: 1411 www.example.com. 7200 IN CNAME svc.example.net. 1412 example.com. 7200 IN HTTPSSVC 0 svc.example.net. 1413 svc.example.net. 7200 IN HTTPSSVC 2 svc3.example.net. ( 1414 alpn=h3 port=8003 esniconfig="ABC..." ) 1415 svc.example.net. 7200 IN HTTPSSVC 3 . ( 1416 alpn=h2 port=8002 esniconfig="123..." ) 1418 is equivalent to the Alt-Svc record: 1420 Alt-Svc: h3="svc3.example.net:8003"; esniconfig="ABC..."; ma=7200, \ 1421 h2="svc.example.net:8002"; esniconfig="123..."; ma=7200 1423 for the origins of both "https://www.example.com" and 1424 "https://example.com". 1426 Appendix B. Comparison with alternatives 1428 The SVCB and HTTPSSVC record types closely resemble, and are inspired 1429 by, some existing record types and proposals. A complaint with all 1430 of the alternatives is that web clients have seemed unenthusiastic 1431 about implementing them. The hope here is that by providing an 1432 extensible solution that solves multiple problems we will overcome 1433 the inertia and have a path to achieve client implementation. 1435 B.1. Differences from the SRV RR type 1437 An SRV record [RFC2782] can perform a similar function to the SVCB 1438 record, informing a client to look in a different location for a 1439 service. However, there are several differences: 1441 o SRV records are typically mandatory, whereas clients will always 1442 continue to function correctly without making use of Alt-Svc or 1443 SVCB. 1445 o SRV records cannot instruct the client to switch or upgrade 1446 protocols, whereas Alt-Svc can signal such an upgrade (e.g. to 1447 HTTP/2). 1449 o SRV records are not extensible, whereas SVCB and HTTPSSVC can be 1450 extended with new parameters. 1452 o Using SRV records would not allow an HTTPS client to skip 1453 processing of the Alt-Svc information in a subsequent connection, 1454 so it does not confer a performance advantage. 1456 B.2. Differences from the proposed HTTP record 1458 Unlike [I-D.draft-bellis-dnsop-http-record-00], this approach is 1459 extensible to cover Alt-Svc and ESNI use-cases. Like that proposal, 1460 this addresses the zone apex CNAME challenge. 1462 Like that proposal it remains necessary to continue to include 1463 address records at the zone apex for legacy clients. 1465 B.3. Differences from the proposed ANAME record 1467 Unlike [I-D.draft-ietf-dnsop-aname-03], this approach is extensible 1468 to cover Alt-Svc and ESNI use-cases. This approach also does not 1469 require any changes or special handling on either authoritative or 1470 master servers, beyond optionally returning in-bailiwick additional 1471 records. 1473 Like that proposal, this addresses the zone apex CNAME challenge for 1474 clients that implement this. 1476 However with this SVCB proposal it remains necessary to continue to 1477 include address records at the zone apex for legacy clients. If 1478 deployment of this standard is successful, the number of legacy 1479 clients will fall over time. As the number of legacy clients 1480 declines, the operational effort required to serve these users 1481 without the benefit of SVCB indirection should fall. Server 1482 operators can easily observe how much traffic reaches this legacy 1483 endpoint, and may remove the apex's address records if the observed 1484 legacy traffic has fallen to negligible levels. 1486 B.4. Differences from the proposed ESNI record 1488 Unlike [ESNI], this approach is extensible and covers the Alt-Svc 1489 case as well as addresses the zone apex CNAME challenge. 1491 By using the Alt-Svc model we also provide a way to solve the ESNI 1492 multi-CDN challenges in a general case. 1494 Unlike ESNI, SVCB allows specifying different ESNI configurations for 1495 different protocols and ports, rather than applying a single 1496 configuration to all ports on a domain. 1498 B.5. SNI Alt-Svc parameter 1500 Defining an Alt-Svc sni= parameter (such as from [AltSvcSNI]) would 1501 have provided some benefits to clients and servers not implementing 1502 ESNI, such as for specifying that "_wildcard.example.com" could be 1503 sent as an SNI value rather than the full name. There is nothing 1504 precluding SVCB from being used with an sni= parameter if one were to 1505 be defined, but it is not included here to reduce scope, complexity, 1506 and additional potential security and tracking risks. 1508 Appendix C. Design Considerations and Open Issues 1510 This draft is intended to be a work-in-progress for discussion. Many 1511 details are expected to change with subsequent refinement. Some 1512 known issues or topics for discussion are listed below. 1514 C.1. Record Name 1516 Naming is hard. "SVCB" and "HTTPSSVC" are proposed as placeholders 1517 that are easy to search for and replace when a final name is chosen. 1518 Other names for this record might include B, ALTSVC, HTTPS, HTTPSSRV, 1519 HTTPSSVC, SVCHTTPS, or something else. 1521 C.2. Generality 1523 The SVCB record was designed as a generalization of HTTPSSVC, based 1524 on feedback requesting a solution that applied to protocols pther 1525 than HTTP. Past efforts to over-generalize have not met with broad 1526 success, but we hope that HTTPSSVC and SVCB have struck an acceptable 1527 balance between generality and focus. 1529 C.3. Wire Format 1531 Advice from experts in DNS wire format best practices would be 1532 greatly appreciated to refine the proposed details, overall. 1534 C.4. Where to include Priority 1536 The SvcFieldPriority could alternately be included as a pri= Alt-Svc 1537 attribute. It wouldn't be applicable for Alt-Svc returned via HTTP, 1538 but it is also not necessarily needed by DNS servers. It is also not 1539 used for AliasForm RRs. 1541 C.5. Whether to include Weight 1543 Some other similar mechanisms such as SRV have a weight in-addition 1544 to priority. That is excluded here for simplicity. It could always 1545 be added as an optional SVCB parameter. 1547 Appendix D. Change history 1549 o draft-ietf-dnsop-svcb-httpssvc-01 1551 * Reduce the emphasis on conversion between HTTPSSVC and Alt-Svc 1553 * Make the "untrusted channel" concept more precise. 1555 * Make SvcFieldPriority = 0 the definition of AliasForm, instead 1556 of a requirement. 1558 o draft-ietf-dnsop-svcb-httpssvc-00 1560 * Document an optimization for optimistic pre-connection. (Chris 1561 Wood) 1563 * Relax IP hint handling requirements. (Eric Rescorla) 1565 o draft-nygren-dnsop-svcb-httpssvc-00 1567 * Generalize to an SVCB record, with special-case handling for 1568 Alt-Svc and HTTPS separated out to dedicated sections. 1570 * Split out a separate HTTPSSVC record for the HTTPS use-case. 1572 * Remove the explicit SvcRecordType=0/1 and instead make the 1573 AliasForm vs ServiceForm be implicit. This was based on 1574 feedback recommending against subtyping RR type. 1576 * Remove one optimization. 1578 o draft-nygren-httpbis-httpssvc-03 1580 * Change redirect type for HSTS-style behavior from 302 to 307 to 1581 reduce ambiguities. 1583 o draft-nygren-httpbis-httpssvc-02 1585 * Remove the redundant length fields from the wire format. 1587 * Define a SvcDomainName of "." for SvcRecordType=1 as being the 1588 HTTPSSVC RRNAME. 1590 * Replace "hq" with "h3". 1592 o draft-nygren-httpbis-httpssvc-01 1594 * Fixes of record name. Replace references to "HTTPSVC" with 1595 "HTTPSSVC". 1597 o draft-nygren-httpbis-httpssvc-00 1599 * Initial version 1601 Authors' Addresses 1603 Ben Schwartz 1604 Google 1606 Email: bemasc@google.com 1607 Mike Bishop 1608 Akamai Technologies 1610 Email: mbishop@evequefou.be 1612 Erik Nygren 1613 Akamai Technologies 1615 Email: erik+ietf@nygren.org