draft-ietf-dnsop-svcb-https-00.txt   draft-ietf-dnsop-svcb-https-01.txt 
DNSOP Working Group B. Schwartz DNSOP Working Group B. Schwartz
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track M. Bishop Intended status: Standards Track M. Bishop
Expires: December 14, 2020 E. Nygren Expires: January 14, 2021 E. Nygren
Akamai Technologies Akamai Technologies
June 12, 2020 July 13, 2020
Service binding and parameter specification via the DNS (DNS SVCB and Service binding and parameter specification via the DNS (DNS SVCB and
HTTPS RRs) HTTPS RRs)
draft-ietf-dnsop-svcb-https-00 draft-ietf-dnsop-svcb-https-01
Abstract Abstract
This document specifies the "SVCB" and "HTTPS" DNS resource record This document specifies the "SVCB" and "HTTPS" DNS resource record
(RR) types to facilitate the lookup of information needed to make (RR) types to facilitate the lookup of information needed to make
connections for origin resources, such as for HTTPS URLs. SVCB connections to network services, such as for HTTPS origins. SVCB
records allow an origin to be served from multiple network locations, records allow a service to be provided from multiple alternative
each with associated parameters (such as transport protocol endpoints, each with associated parameters (such as transport
configuration and keys for encrypting the TLS ClientHello). They protocol configuration and keys for encrypting the TLS ClientHello).
also enable aliasing of apex domains, which is not possible with They also enable aliasing of apex domains, which is not possible with
CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP
origins. By providing more information to the client before it origins. By providing more information to the client before it
attempts to establish a connection, these records offer potential attempts to establish a connection, these records offer potential
benefits to both performance and privacy. benefits to both performance and privacy.
TO BE REMOVED: This proposal is inspired by and based on recent DNS TO BE REMOVED: This proposal is inspired by and based on recent DNS
usage proposals such as ALTSVC, ANAME, and ESNIKEYS (as well as long usage proposals such as ALTSVC, ANAME, and ESNIKEYS (as well as long
standing desires to have SRV or a functional equivalent implemented standing desires to have SRV or a functional equivalent implemented
for HTTP). These proposals each provide an important function but for HTTP). These proposals each provide an important function but
are potentially incompatible with each other, such as when an origin are potentially incompatible with each other, such as when an origin
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 14, 2020. This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 40 skipping to change at page 2, line 40
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Goals of the SVCB RR . . . . . . . . . . . . . . . . . . 5 1.1. Goals of the SVCB RR . . . . . . . . . . . . . . . . . . 5
1.2. Overview of the SVCB RR . . . . . . . . . . . . . . . . . 6 1.2. Overview of the SVCB RR . . . . . . . . . . . . . . . . . 6
1.3. Parameter for Encrypted ClientHello . . . . . . . . . . . 7 1.3. Parameter for Encrypted ClientHello . . . . . . . . . . . 7
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. The SVCB record type . . . . . . . . . . . . . . . . . . . . 7 2. The SVCB record type . . . . . . . . . . . . . . . . . . . . 7
2.1. Presentation format . . . . . . . . . . . . . . . . . . . 8 2.1. Zone file presentation format . . . . . . . . . . . . . . 8
2.1.1. Presentation format for SvcFieldValue key=value pairs 8 2.2. RDATA wire format . . . . . . . . . . . . . . . . . . . . 9
2.2. SVCB RDATA Wire Format . . . . . . . . . . . . . . . . . 9
2.3. SVCB owner names . . . . . . . . . . . . . . . . . . . . 10 2.3. SVCB owner names . . . . . . . . . . . . . . . . . . . . 10
2.4. SvcRecordType . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5. SVCB records: AliasForm . . . . . . . . . . . . . . . . . 11 2.4.1. AliasMode . . . . . . . . . . . . . . . . . . . . . . 11
2.6. SVCB records: ServiceForm . . . . . . . . . . . . . . . . 12 2.4.2. ServiceMode . . . . . . . . . . . . . . . . . . . . . 12
2.6.1. Special handling of "." for SvcDomainName in 2.4.3. SvcPriority . . . . . . . . . . . . . . . . . . . . . 12
ServiceForm . . . . . . . . . . . . . . . . . . . . . 12 2.5. Special handling of "." in TargetName . . . . . . . . . . 12
2.6.2. SvcFieldPriority . . . . . . . . . . . . . . . . . . 13 2.5.1. AliasMode . . . . . . . . . . . . . . . . . . . . . . 13
2.5.2. ServiceMode . . . . . . . . . . . . . . . . . . . . . 13
3. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 13 3. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Handling resolution failures . . . . . . . . . . . . . . 14 3.1. Handling resolution failures . . . . . . . . . . . . . . 14
3.2. Clients using a Proxy . . . . . . . . . . . . . . . . . . 14 3.2. Clients using a Proxy . . . . . . . . . . . . . . . . . . 14
4. DNS Server Behavior . . . . . . . . . . . . . . . . . . . . . 15 4. DNS Server Behavior . . . . . . . . . . . . . . . . . . . . . 15
4.1. Authoritative servers . . . . . . . . . . . . . . . . . . 15 4.1. Authoritative servers . . . . . . . . . . . . . . . . . . 15
4.2. Recursive resolvers . . . . . . . . . . . . . . . . . . . 15 4.2. Recursive resolvers . . . . . . . . . . . . . . . . . . . 15
4.3. General requirements . . . . . . . . . . . . . . . . . . 16 4.3. General requirements . . . . . . . . . . . . . . . . . . 16
5. Performance optimizations . . . . . . . . . . . . . . . . . . 16 5. Performance optimizations . . . . . . . . . . . . . . . . . . 16
5.1. Optimistic pre-connection and connection reuse . . . . . 16 5.1. Optimistic pre-connection and connection reuse . . . . . 17
5.2. Generating and using incomplete responses . . . . . . . . 17 5.2. Generating and using incomplete responses . . . . . . . . 17
5.3. Structuring zones for performance . . . . . . . . . . . . 17 5.3. Structuring zones for performance . . . . . . . . . . . . 18
6. Initial SvcParamKeys . . . . . . . . . . . . . . . . . . . . 18 6. Initial SvcParamKeys . . . . . . . . . . . . . . . . . . . . 18
6.1. "alpn" and "no-default-alpn" . . . . . . . . . . . . . . 18 6.1. "alpn" and "no-default-alpn" . . . . . . . . . . . . . . 18
6.2. "port" . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2. "port" . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3. "echconfig" . . . . . . . . . . . . . . . . . . . . . . . 20 6.3. "echconfig" . . . . . . . . . . . . . . . . . . . . . . . 20
6.4. "ipv4hint" and "ipv6hint" . . . . . . . . . . . . . . . . 20 6.4. "ipv4hint" and "ipv6hint" . . . . . . . . . . . . . . . . 21
7. Using SVCB with HTTPS and HTTP . . . . . . . . . . . . . . . 21 6.5. "mandatory" . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Owner names for HTTPS RRs . . . . . . . . . . . . . . . . 21 7. Using SVCB with HTTPS and HTTP . . . . . . . . . . . . . . . 22
7.2. Relationship to Alt-Svc . . . . . . . . . . . . . . . . . 22 7.1. Owner names for HTTPS RRs . . . . . . . . . . . . . . . . 23
7.2.1. ALPN usage . . . . . . . . . . . . . . . . . . . . . 22 7.2. Relationship to Alt-Svc . . . . . . . . . . . . . . . . . 24
7.2.2. Untrusted channel . . . . . . . . . . . . . . . . . . 22 7.2.1. ALPN usage . . . . . . . . . . . . . . . . . . . . . 24
7.2.3. TTL and granularity . . . . . . . . . . . . . . . . . 23 7.2.2. Untrusted channel . . . . . . . . . . . . . . . . . . 24
7.3. Interaction with Alt-Svc . . . . . . . . . . . . . . . . 23 7.2.3. TTL and granularity . . . . . . . . . . . . . . . . . 24
7.4. Requiring Server Name Indication . . . . . . . . . . . . 23 7.3. Interaction with Alt-Svc . . . . . . . . . . . . . . . . 25
7.5. HTTP Strict Transport Security . . . . . . . . . . . . . 24 7.4. Requiring Server Name Indication . . . . . . . . . . . . 25
7.6. HTTP-based protocols . . . . . . . . . . . . . . . . . . 24 7.5. HTTP Strict Transport Security . . . . . . . . . . . . . 25
8. SVCB/HTTPS RR parameter for ECH configuration . . . . . . . . 25 7.6. HTTP-based protocols . . . . . . . . . . . . . . . . . . 26
8.1. Client behavior . . . . . . . . . . . . . . . . . . . . . 25 8. SVCB/HTTPS RR parameter for ECH configuration . . . . . . . . 26
8.2. Deployment considerations . . . . . . . . . . . . . . . . 25 8.1. Client behavior . . . . . . . . . . . . . . . . . . . . . 27
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.2. Deployment considerations . . . . . . . . . . . . . . . . 27
9.1. Protocol enhancements . . . . . . . . . . . . . . . . . . 26 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2. Apex aliasing . . . . . . . . . . . . . . . . . . . . . . 26 9.1. Protocol enhancements . . . . . . . . . . . . . . . . . . 27
9.3. Parameter binding . . . . . . . . . . . . . . . . . . . . 27 9.2. Apex aliasing . . . . . . . . . . . . . . . . . . . . . . 28
9.4. Non-HTTPS uses . . . . . . . . . . . . . . . . . . . . . 27 9.3. Parameter binding . . . . . . . . . . . . . . . . . . . . 28
10. Interaction with other standards . . . . . . . . . . . . . . 27 9.4. Non-HTTPS uses . . . . . . . . . . . . . . . . . . . . . 29
11. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Interaction with other standards . . . . . . . . . . . . . . 29
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29
12.1. New registry for Service Parameters . . . . . . . . . . 28 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . 28 12.1. SVCB RRType . . . . . . . . . . . . . . . . . . . . . . 30
12.1.2. Initial contents . . . . . . . . . . . . . . . . . . 29 12.2. HTTPS RRType . . . . . . . . . . . . . . . . . . . . . . 30
12.2. Registry updates . . . . . . . . . . . . . . . . . . . . 30 12.3. New registry for Service Parameters . . . . . . . . . . 31
13. Acknowledgments and Related Proposals . . . . . . . . . . . . 31 12.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . 31
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 12.3.2. Initial contents . . . . . . . . . . . . . . . . . . 31
14.1. Normative References . . . . . . . . . . . . . . . . . . 31 12.4. Registry updates . . . . . . . . . . . . . . . . . . . . 32
14.2. Informative References . . . . . . . . . . . . . . . . . 34 13. Acknowledgments and Related Proposals . . . . . . . . . . . . 33
14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Comparison with alternatives . . . . . . . . . . . . 35 14.1. Normative References . . . . . . . . . . . . . . . . . . 33
A.1. Differences from the SRV RR type . . . . . . . . . . . . 35 14.2. Informative References . . . . . . . . . . . . . . . . . 36
A.2. Differences from the proposed HTTP record . . . . . . . . 35 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.3. Differences from the proposed ANAME record . . . . . . . 35 Appendix A. Decoding text in zone files . . . . . . . . . . . . 37
A.4. Comparison with separate RR types for AliasForm and A.1. Decoding a value list . . . . . . . . . . . . . . . . . . 37
ServiceForm . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. Change history . . . . . . . . . . . . . . . . . . . 36 Appendix B. Comparison with alternatives . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 B.1. Differences from the SRV RR type . . . . . . . . . . . . 38
B.2. Differences from the proposed HTTP record . . . . . . . . 39
B.3. Differences from the proposed ANAME record . . . . . . . 39
B.4. Comparison with separate RR types for AliasMode and
ServiceMode . . . . . . . . . . . . . . . . . . . . . . . 39
Appendix C. Change history . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
The SVCB and HTTPS RRs provide clients with complete instructions for The SVCB and HTTPS RRs provide clients with complete instructions for
access to an origin. This information enables improved performance access to a service. This information enables improved performance
and privacy by avoiding transient connections to a sub-optimal and privacy by avoiding transient connections to a sub-optimal
default server, negotiating a preferred protocol, and providing default server, negotiating a preferred protocol, and providing
relevant public keys. relevant public keys.
For example, when clients need to make a connection to fetch For example, when clients need to make a connection to fetch
resources associated with an HTTPS URI, they currently resolve only A resources associated with an HTTPS URI, they currently resolve only A
and/or AAAA records for the origin hostname. This is adequate for and/or AAAA records for the origin hostname. This is adequate for
services that use basic HTTPS (fixed port, no QUIC, no [ECH]). Going services that use basic HTTPS (fixed port, no QUIC, no [ECH]). Going
beyond basic HTTPS confers privacy, performance, and operational beyond basic HTTPS confers privacy, performance, and operational
advantages, but it requires the client to learn additional advantages, but it requires the client to learn additional
information, and it is highly desirable to minimize the number of information, and it is highly desirable to minimize the number of
round-trips and lookups required to learn this additional round-trips and lookups required to learn this additional
information. information.
The SVCB and HTTPS RRs also help when the operator of an origin The SVCB and HTTPS RRs also help when the operator of a service
wishes to delegate operational control to one or more other domains, wishes to delegate operational control to one or more other domains,
e.g. delegating the origin resource "https://example.com" to a e.g. delegating the origin "https://example.com" to a service
service operator endpoint at "svc.example.net". While this case can operator endpoint at "svc.example.net". While this case can
sometimes be handled by a CNAME, that does not cover all use-cases. sometimes be handled by a CNAME, that does not cover all use-cases.
CNAME is also inadequate when the service operator needs to provide a CNAME is also inadequate when the service operator needs to provide a
bound collection of consistent configuration parameters through the bound collection of consistent configuration parameters through the
DNS (such as network location, protocol, and keying information). DNS (such as network location, protocol, and keying information).
This document first describes the SVCB RR as a general-purpose This document first describes the SVCB RR as a general-purpose
resource record that can be applied directly and efficiently to a resource record that can be applied directly and efficiently to a
wide range of services (Section 2). The HTTPS RR is then defined as wide range of services (Section 2). The HTTPS RR is then defined as
a special case of SVCB that improves efficiency and convenience for a special case of SVCB that improves efficiency and convenience for
use with HTTPS (Section 7) by avoiding the need for an [Attrleaf] use with HTTPS (Section 7) by avoiding the need for an Attrleaf label
label (Section 7.1). Other protocols with similar needs may follow [Attrleaf] (Section 7.1). Other protocols with similar needs may
the pattern of HTTPS and assign their own SVCB-compatible RR types. follow the pattern of HTTPS and assign their own SVCB-compatible RR
types.
All behaviors described as applying to the SVCB RR also apply to the All behaviors described as applying to the SVCB RR also apply to the
HTTPS RR unless explicitly stated otherwise. Section 7 describes HTTPS RR unless explicitly stated otherwise. Section 7 describes
additional behaviors specific to the HTTPS RR. Apart from Section 7 additional behaviors specific to the HTTPS RR. Apart from Section 7
and introductory examples, much of this document refers only to the and introductory examples, much of this document refers only to the
SVCB RR, but those references should be taken to apply to SVCB, SVCB RR, but those references should be taken to apply to SVCB,
HTTPS, and any future SVCB-compatible RR types. HTTPS, and any future SVCB-compatible RR types.
The SVCB RR has two forms: 1) the "Alias Form" simply delegates The SVCB RR has two modes: 1) "AliasMode" simply delegates
operational control for a resource; 2) the "Service Form" binds operational control for a resource; 2) "ServiceMode" binds together
together configuration information for a service endpoint. The configuration information for a service endpoint. ServiceMode
Service Form provides additional key=value parameters within each provides additional key=value parameters within each RDATA set.
RDATA set.
TO BE REMOVED: If we use this for providing configuration for DNS TO BE REMOVED: If we use this for providing configuration for DNS
authorities, it is likely we'd specify a distinct "NS2" RR type that authorities, it is likely we'd specify a distinct "NS2" RR type that
is an instantiation of SVCB for authoritative nameserver delegation is an instantiation of SVCB for authoritative nameserver delegation
and parameter specification, similar to HTTPS. See and parameter specification, similar to HTTPS. See [I-D.tapril-ns2]
[I-D.draft-tapril-ns2-00] as one example. as one example.
1.1. Goals of the SVCB RR 1.1. Goals of the SVCB RR
The goal of the SVCB RR is to allow clients to resolve a single The goal of the SVCB RR is to allow clients to resolve a single
additional DNS RR in a way that: additional DNS RR in a way that:
o Provides service endpoints authoritative for the service, along o Provides alternative endpoints that are authoritative for the
with parameters associated with each of these endpoints. service, along with parameters associated with each of these
endpoints.
o Does not assume that all alternative service endpoints have the o Does not assume that all alternative endpoints have the same
same parameters or capabilities, or are even operated by the same parameters or capabilities, or are even operated by the same
entity. This is important as DNS does not provide any way to tie entity. This is important as DNS does not provide any way to tie
together multiple RRs for the same name. For example, if together multiple RRs for the same name. For example, if
www.example.com is a CNAME alias that switches between one of www.example.com is a CNAME alias that switches between one of
three CDNs or hosting environments, successive queries for that three CDNs or hosting environments, successive queries for that
name may return records that correspond to different environments. name may return records that correspond to different environments.
o Enables CNAME-like functionality at a zone apex (such as o Enables CNAME-like functionality at a zone apex (such as
"example.com") for participating protocols, and generally enables "example.com") for participating protocols, and generally enables
delegation of operational authority for an origin within the DNS delegation of operational authority for an origin within the DNS
to an alternate name. to an alternate name.
Additional goals specific to HTTPS RRs and the HTTPS use-case Additional goals specific to HTTPS RRs and the HTTPS use-case
include: include:
o Connect directly to [HTTP3] (QUIC transport) alternative service o Connect directly to HTTP3 (QUIC transport) alternative endpoints
endpoints [HTTP3]
o Obtain the [ECH] keys associated with an alternative service o Obtain the Encrypted ClientHello [ECH] keys associated with an
endpoint alternative endpoint
o Support non-default TCP and UDP ports o Support non-default TCP and UDP ports
o Enable SRV-like benefits (e.g. apex delegation, as mentioned
above) for HTTP(S), where SRV [SRV] has not been widely adopted
o Address a set of long-standing issues due to HTTP(S) clients not o Provide an HSTS-like indication [HSTS] signaling that the HTTPS
implementing support for SRV records, as well as due to a scheme should be used instead of HTTP for this request (see
limitation that a DNS name can not have both CNAME and NS RRs (as Section 7.5).
is the case for zone apex names)
o Provide an HSTS-like indication signaling for the duration of the
DNS RR TTL that the HTTPS scheme should be used instead of HTTP
(see Section 7.5).
1.2. Overview of the SVCB RR 1.2. Overview of the SVCB RR
This subsection briefly describes the SVCB RR in a non-normative This subsection briefly describes the SVCB RR in a non-normative
manner. (As mentioned above, this all applies equally to the HTTPS manner. (As mentioned above, this all applies equally to the HTTPS
RR which shares the same encoding, format, and high-level semantics.) RR which shares the same encoding, format, and high-level semantics.)
The SVCB RR has two forms: AliasForm, which aliases a name to another The SVCB RR has two modes: AliasMode, which aliases a name to another
name, and ServiceForm, which provides connection information bound to name, and ServiceMode, which provides connection information bound to
a service endpoint domain. Placing both forms in a single RR type a service endpoint domain. Placing both forms in a single RR type
allows clients to fetch the relevant information with a single query. allows clients to fetch the relevant information with a single query.
The SVCB RR has two mandatory fields and one optional. The fields The SVCB RR has two mandatory fields and one optional. The fields
are: are:
1. SvcFieldPriority: The priority of this record (relative to 1. SvcPriority: The priority of this record (relative to others,
others, with lower values preferred). A value of 0 indicates with lower values preferred). A value of 0 indicates AliasMode.
AliasForm. (Described in Section 2.6.2.) (Described in Section 2.4.3.)
2. SvcDomainName: The domain name of either the alias target (for 2. TargetName: The domain name of either the alias target (for
AliasForm) or the alternative service endpoint (for ServiceForm). AliasMode) or the alternative endpoint (for ServiceMode).
3. SvcFieldValue (optional): A list of key=value pairs describing 3. SvcParams (optional): A list of key=value pairs describing the
the alternative service endpoint for the domain name specified in alternative endpoint at TargetName (only used in ServiceMode and
SvcDomainName (only used in ServiceForm and otherwise ignored). otherwise ignored). Described in Section 2.1.
Described in Section 2.1.1.
Cooperating DNS recursive resolvers will perform subsequent record Cooperating DNS recursive resolvers will perform subsequent record
resolution (for SVCB, A, and AAAA records) and return them in the resolution (for SVCB, A, and AAAA records) and return them in the
Additional Section of the response. Clients must either use Additional Section of the response. Clients either use responses
responses included in the additional section returned by the included in the additional section returned by the recursive resolver
recursive resolver or perform necessary SVCB, A, and AAAA record or perform necessary SVCB, A, and AAAA record resolutions. DNS
resolutions. DNS authoritative servers may attach in-bailiwick SVCB, authoritative servers can attach in-bailiwick SVCB, A, AAAA, and
A, AAAA, and CNAME records in the Additional Section to responses for CNAME records in the Additional Section to responses for a SVCB
a SVCB query. query.
When in the ServiceForm, the SvcFieldValue of the SVCB RR provides an In ServiceMode, the SvcParams of the SVCB RR provide an extensible
extensible data model for describing network endpoints that are data model for describing alternative endpoints that are
authoritative for the origin, along with parameters associated with authoritative for the origin, along with parameters associated with
each of these endpoints. each of these alternative endpoints.
For the HTTPS use-case, the HTTPS RR enables many of the benefits of For the HTTPS use-case, the HTTPS RR enables many of the benefits of
[AltSvc] without waiting for a full HTTP connection initiation Alt-Svc [AltSvc] without waiting for a full HTTP connection
(multiple roundtrips) before learning of the preferred alternative, initiation (multiple roundtrips) before learning of the preferred
and without necessarily revealing the user's intended destination to alternative, and without necessarily revealing the user's intended
all entities along the network path. destination to all entities along the network path.
1.3. Parameter for Encrypted ClientHello 1.3. Parameter for Encrypted ClientHello
This document also defines a parameter for Encrypted ClientHello This document also defines a parameter for Encrypted ClientHello
[ECH] keys. See Section 8. [ECH] keys. See Section 8.
1.4. Terminology 1.4. Terminology
For consistency with [AltSvc], we adopt the following definitions: Our terminology is based on the common case where the SVCB record is
used to access a resource identified by a URI whose "authority" field
contains a DNS hostname as the "host".
o An "origin" is an information source as in [RFC6454]. For o The "service" is the information source identified by the
services other than HTTPS, the exact definition will need to be "authority" and "scheme" of the URI, capable of providing access
provided by the document mapping that service onto the SVCB RR. to the resource. For HTTPS URIs, the "service" corresponds to an
HTTPS "origin" [RFC6454].
o The "origin server" is the server that the client would reach when o The "service name" is the "host" portion of the authority.
accessing the origin in the absence of the SVCB record or an HTTPS
Alt-Svc.
o An "alternative service" is a different server that can serve the o The "authority endpoint" is the authority's hostname and a port
origin over a specified protocol. number implied by the scheme or specified in the URI.
For example within HTTPS, the origin consists of a scheme (typically o An "alternative endpoint" is a hostname, port number, and other
"https"), a hostname, and a port (typically "443"). associated instructions to the client on how to reach an instance
of service.
Additional DNS terminology intends to be consistent with [DNSTerm]. Additional DNS terminology intends to be consistent with [DNSTerm].
SVCB is a contraction of "service binding". The SVCB RR, HTTPS RR, SVCB is a contraction of "service binding". The SVCB RR, HTTPS RR,
and future RR types that share SVCB's format and registry are and future RR types that share SVCB's format and registry are
collectively known as SVCB-compatible RR types. collectively known as SVCB-compatible RR types.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. The SVCB record type 2. The SVCB record type
The SVCB DNS resource record (RR) type (RR type ???) is used to The SVCB DNS resource record (RR) type (RR type 64) is used to locate
locate endpoints that can service an origin. There is special alternative endpoints for a service.
handling for the case of "https" origins.
The algorithm for resolving SVCB records and associated address The algorithm for resolving SVCB records and associated address
records is specified in Section 3. records is specified in Section 3.
2.1. Presentation format Other SVCB-compatible resource record types can also be defined as-
needed. In particular, the HTTPS RR (RR type 65) provides special
handling for the case of "https" origins as described in Section 7.
The presentation format of the record is: SVCB RRs are extensible by a list of SvcParams, which are pairs
consisting of a SvcParamKey and a SvcParamValue. Each SvcParamKey
has a presentation name and a registered number. Values are in a
format specific to the SvcParamKey. Their definition should specify
both their presentation format and wire encoding (e.g., domain names,
binary data, or numeric values). The initial SvcParamKeys and
formats are defined in Section 6.
Name TTL IN SVCB SvcFieldPriority SvcDomainName SvcFieldValue 2.1. Zone file presentation format
The SVCB record is defined specifically within the Internet ("IN") The presentation format of the record is:
Class ([RFC1035]). SvcFieldPriority is a number in the range
0-65535, SvcDomainName is a domain name (absolute or relative), and
SvcFieldValue is a set of key=value pairs present for the
ServiceForm. Each key SHALL appear at most once in an SvcFieldValue.
The SvcFieldValue is empty for the AliasForm.
2.1.1. Presentation format for SvcFieldValue key=value pairs Name TTL IN SVCB SvcPriority TargetName SvcParams
In ServiceForm, the SvcFieldValue consists of zero or more elements The SVCB record is defined specifically within the Internet ("IN")
separated by whitespace. Each element represents a key=value pair. Class ([RFC1035]).
Keys are IANA-registered SvcParamKeys (Section 12.1) with both a SvcPriority is a number in the range 0-65535, TargetName is a domain
case-insensitive string representation and a numeric representation name, and the SvcParams are a whitespace-separated list, with each
in the range 0-65535. Registered key names should only contain SvcParam consisting of a SvcParamKey=SvcParamValue pair or a
characters from the ranges "a"-"z", "0"-"9", and "-". In ABNF standalone SvcParamKey. SvcParamKeys are subject to IANA control
[RFC5234], (Section 12.3).
ALPHA-LC = %x61-7A ; a-z Each SvcParamKey SHALL appear at most once in the SvcParams. In
key = 1*(ALPHA-LC / DIGIT / "-") presentation format, SvcParamKeys are lower-case alphanumeric
display-key = 1*(ALPHA / DIGIT / "-") strings. Key names should contain 1-63 characters from the ranges
"a"-"z", "0"-"9", and "-". In ABNF [RFC5234],
Values are in a format specific to the SvcParamKey. Their definition alpha-lc = %x61-7A ; a-z
should specify both their presentation format and wire encoding SvcParamKey = 1*63(alpha-lc / DIGIT / "-")
(e.g., domain names, binary data, or numeric values). The initial SvcParam = SvcParamKey ["=" SvcParamValue]
keys and formats are defined in Section 6. SvcParamValue = char-string
value = *OCTET
The presentation format for SvcFieldValue is a whitespace-separated The definition of each SvcParamKey indicates that its SvcParamValue
list of key=value pairs. When the value is omitted, or both the is empty, single-valued, or multi-valued. To parse a single-valued
value and the "=" are omitted, the presentation value is the empty SvcParam, the parser applies the character-string decoding algorithm
string. (Appendix A), producing a "value", and then performs key-specific
processing to validate the input and produce the wire-format
encoding. To parse a multi-valued SvcParam, the parser applies the
value-list decoding algorithm to the "char-string" (Appendix A.1),
splitting on unescaped commas to produce a list of zero or more
values.
; basic-visible is VCHAR minus DQUOTE, ";", "(", ")", and "\". When the "=" is omitted, the "value" or value list is interpreted as
basic-visible = %x21 / %x23-27 / %2A-3A / %x3C-5B / %x5D-7E empty.
escaped-char = "\" (VCHAR / WSP)
contiguous = 1*(basic-visible / escaped-char)
quoted-string = DQUOTE *(contiguous / WSP) DQUOTE
value = quoted-string / contiguous
pair = display-key "=" value
element = display-key / pair
The value format is intended to match the definition of <character-
string> in [RFC1035] Section 5.1. (Unlike <character-string>, the
length of a value is not limited to 255 characters.)
Unrecognized keys are represented in presentation format as Unrecognized keys are represented in presentation format as
"keyNNNNN" where NNNNN is the numeric value of the key type without "keyNNNNN" where NNNNN is the numeric value of the key type without
leading zeros. In presentation format, values corresponding to leading zeros. SvcParams in this form are always treated as single-
unrecognized keys SHALL be represented in wire format, using decimal valued, and the decoded "value" SHALL be used as its wire format
escape codes (e.g. \255) when necessary. encoding.
When decoding values of unrecognized keys in the presentation format:
o a character other than "\" represents its ASCII value in wire
format.
o the character "\" followed by three decimal digits, up to 255,
represents an octet in the wire format.
o the character "\" followed by any allowed character, except a
decimal digit, represents the subsequent character's ASCII value.
Elements in presentation format MAY appear in any order, but keys SvcParams in presentation format MAY appear in any order, but keys
MUST NOT be repeated. MUST NOT be repeated.
2.2. SVCB RDATA Wire Format 2.2. RDATA wire format
The RDATA for the SVCB RR consists of: The RDATA for the SVCB RR consists of:
o a 2 octet field for SvcFieldPriority as an integer in network byte o a 2 octet field for SvcPriority as an integer in network byte
order. order.
o the uncompressed, fully-qualified SvcDomainName, represented as a o the uncompressed, fully-qualified TargetName, represented as a
sequence of length-prefixed labels as in Section 3.1 of [RFC1035]. sequence of length-prefixed labels as in Section 3.1 of [RFC1035].
o the SvcFieldValue byte string, consuming the remainder of the o the SvcParams, consuming the remainder of the record (so smaller
record (so smaller than 65535 octets and constrained by the RDATA than 65535 octets and constrained by the RDATA and DNS message
and DNS message sizes). sizes).
AliasForm is defined by SvcFieldPriority being 0.
When SvcFieldValue is non-empty (ServiceForm), it contains a series When the list of SvcParams is non-empty (ServiceMode), it contains a
of SvcParamKey=SvcParamValue pairs, represented as: series of SvcParamKey=SvcParamValue pairs, represented as:
o a 2 octet field containing the SvcParamKey as an integer in o a 2 octet field containing the SvcParamKey as an integer in
network byte order. (See Section 12.1.2 for the defined values.) network byte order. (See Section 12.3.2 for the defined values.)
o a 2 octet field containing the length of the SvcParamValue as an o a 2 octet field containing the length of the SvcParamValue as an
integer between 0 and 65535 in network byte order (but constrained integer between 0 and 65535 in network byte order (but constrained
by the RDATA and DNS message sizes). by the RDATA and DNS message sizes).
o an octet string of this length whose contents are in a format o an octet string of this length whose contents are in a format
determined by the SvcParamKey. determined by the SvcParamKey.
SvcParamKeys SHALL appear in increasing numeric order. SvcParamKeys SHALL appear in increasing numeric order.
Clients MUST consider an RR malformed if Clients MUST consider an RR malformed if:
o the parser reaches the end of the RDATA while parsing an o the parser reaches the end of the RDATA while parsing the
SvcFieldValue. SvcParams.
o SvcParamKeys are not in strictly increasing numeric order. o SvcParamKeys are not in strictly increasing numeric order.
o the SvcParamValue for an SvcParamKey does not have the expected o the SvcParamValue for an SvcParamKey does not have the expected
format. format.
Note that the second condition implies that there are no duplicate Note that the second condition implies that there are no duplicate
SvcParamKeys. SvcParamKeys.
If any RRs are malformed, the client MUST reject the entire RRSet and If any RRs are malformed, the client MUST reject the entire RRSet and
fall back to non-SVCB connection establishment. fall back to non-SVCB connection establishment.
TODO: decide if we want special handling for any SvcParamKey ranges?
For example: range for greasing; experimental range; range-of-
mandatory-to-use-the-RR vs range of ignore-just-param-if-unknown.
2.3. SVCB owner names 2.3. SVCB owner names
When querying the SVCB RR, an origin is translated into a QNAME by When querying the SVCB RR, a service is translated into a QNAME by
prepending the hostname with a label indicating the scheme, prefixed prepending the service name with a label indicating the scheme,
with an underscore, resulting in a domain name like prefixed with an underscore, resulting in a domain name like
"_examplescheme.api.example.com.". "_examplescheme.api.example.com.".
Protocol mapping documents MAY specify additional underscore-prefixed Protocol mapping documents MAY specify additional underscore-prefixed
labels to be prepended. For schemes that specify a port labels to be prepended. For schemes that specify a port
(Section 3.2.3 of [URI]), one reasonable possibility is to prepend (Section 3.2.3 of [URI]), one reasonable possibility is to prepend
the indicated port number (or the default if no port number is the indicated port number (or the default if no port number is
specified). We term this behavior "Port Prefix Naming", and use it specified). We term this behavior "Port Prefix Naming", and use it
in the examples throughout this document. in the examples throughout this document.
See Section 7.1 for the HTTPS RR behavior. See Section 7.1 for the HTTPS RR behavior.
When a prior CNAME or SVCB record has aliased to a SVCB record, each When a prior CNAME or SVCB record has aliased to a SVCB record, each
RR shall be returned under its own owner name. RR shall be returned under its own owner name.
Note that none of these forms alter the origin or authority for Note that none of these forms alter the origin or authority for
validation purposes. For example, clients MUST continue to validate validation purposes. For example, TLS clients MUST continue to
TLS certificate hostnames based on the origin host. validate TLS certificates for the original service name.
As an example, the owner of example.com could publish this record As an example, the owner of example.com could publish this record:
_8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net. _8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net.
to indicate that "foo://api.example.com:8443" is aliased to to indicate that "foo://api.example.com:8443" is aliased to
"svc4.example.net". The owner of example.net, in turn, could publish "svc4.example.net". The owner of example.net, in turn, could publish
this record this record:
svc4.example.net. 7200 IN SVCB 3 svc4.example.net. ( svc4.example.net. 7200 IN SVCB 3 svc4.example.net. (
alpn="bar" port="8004" echconfig="..." ) alpn="bar" port="8004" echconfig="..." )
to indicate that these services are served on port number 8004, which to indicate that these services are served on port number 8004, which
supports the protocol "bar" and its associated transport in addition supports the protocol "bar" and its associated transport in addition
to the default transport protocol for "foo://". to the default transport protocol for "foo://".
(Parentheses are used to ignore a line break ([RFC1035] (Parentheses are used to ignore a line break ([RFC1035]
Section 5.1).) Section 5.1).)
2.4. SvcRecordType 2.4. Modes
The SvcRecordType is indicated by the SvcFieldPriority, and defines When SvcPriority is 0 the SVCB record is in AliasMode. Otherwise, it
the form of the SVCB RR. When SvcFieldPriority is 0, the SVCB is in ServiceMode.
SvcRecordType is defined to be in AliasForm. Otherwise, the SVCB
SvcRecordType is defined to be in ServiceForm.
Within a SVCB RRSet, all RRs should have the same SvcRecordType. If Within a SVCB RRSet, all RRs SHOULD have the same Mode. If an RRSet
an RRSet contains a record in AliasForm, the client MUST ignore any contains a record in AliasMode, the recipient MUST ignore any
records in the set with ServiceForm. ServiceMode records in the set.
2.5. SVCB records: AliasForm 2.4.1. AliasMode
When SvcRecordType is AliasForm, the SVCB record is to be treated In AliasMode, the SVCB record aliases a service to a TargetName.
similar to a CNAME alias pointing to SvcDomainName. SVCB RRSets SVCB RRSets SHOULD only have a single resource record in AliasMode.
SHOULD only have a single resource record in this form. If multiple If multiple are present, clients or recursive resolvers SHOULD pick
are present, clients or recursive resolvers SHOULD pick one at one at random.
random.
The AliasForm's primary purpose is to allow aliasing at the zone The primary purpose of AliasMode is to allow aliasing at the zone
apex, where CNAME is not allowed. For example, if an operator of apex, where CNAME is not allowed. In AliasMode, TargetName MUST be
https://example.com wanted to point HTTPS requests to a service the name of a domain that has SVCB, AAAA, or A records. It MUST NOT
operating at svc.example.net, they would publish a record such as: be equal to the owner name, as this would cause a loop.
example.com. 3600 IN SVCB 0 svc.example.net. For example, the operator of foo://example.com:8080 could point
requests to a service operating at foosvc.example.net by publishing:
In AliasForm, SvcDomainName MUST be the name of a domain that has _8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net.
SVCB, AAAA, or A records. It MUST NOT be equal to the owner name, as
this would cause a loop. Using AliasMode maintains a separation of concerns: the owner of
foosvc.example.net can add or remove ServiceMode SVCB records without
requiring a corresponding change to example.com. Note that if
foosvc.example.net promises to always publish a SVCB record, this
AliasMode record can be replaced by a CNAME, which would likely
improve performance.
AliasMode is especially useful for SVCB-compatible RR types that do
not require an underscore prefix, such as the HTTPS RR type. For
example, the operator of https://example.com could point requests to
a server at svc.example.net by publishing this record at the zone
apex:
example.com. 3600 IN HTTPS 0 svc.example.net.
Note that the SVCB record's owner name MAY be the canonical name of a Note that the SVCB record's owner name MAY be the canonical name of a
CNAME record, and the SvcDomainName MAY be the owner of a CNAME CNAME record, and the TargetName MAY be the owner of a CNAME record.
record. Clients and recursive resolvers MUST follow CNAMEs as Clients and recursive resolvers MUST follow CNAMEs as normal.
normal.
To avoid unbounded alias chains, clients and recursive resolvers MUST To avoid unbounded alias chains, clients and recursive resolvers MUST
impose a limit on the total number of SVCB aliases they will follow impose a limit on the total number of SVCB aliases they will follow
for each resolution request. This limit MUST NOT be zero, i.e. for each resolution request. This limit MUST NOT be zero, i.e.
implementations MUST be able to follow at least one AliasForm record. implementations MUST be able to follow at least one AliasMode record.
The exact value of this limit is left to implementations. The exact value of this limit is left to implementations.
For compatibility and performance, zone owners SHOULD NOT configure For compatibility and performance, zone owners SHOULD NOT configure
their zones to require following multiple AliasForm records. their zones to require following multiple AliasMode records.
As legacy clients will not know to use this record, service operators As legacy clients will not know to use this record, service operators
will likely need to retain fallback AAAA and A records alongside this will likely need to retain fallback AAAA and A records alongside this
SVCB record, although in a common case the target of the SVCB record SVCB record, although in a common case the target of the SVCB record
might offer better performance, and therefore would be preferable for might offer better performance, and therefore would be preferable for
clients implementing this specification to use. clients implementing this specification to use.
Note that SVCB AliasForm RRs do not alias to RR types other than AliasMode records only apply to queries for the specific RR type.
address records (AAAA and A), CNAMEs, and ServiceForm SVCB records. For example, a SVCB record cannot alias to an HTTPS record, nor vice-
For example, an AliasForm SVCB record does not alias to an HTTPS RR, versa.
nor vice-versa.
2.6. SVCB records: ServiceForm 2.4.2. ServiceMode
When SvcRecordType is the ServiceForm, the combination of In ServiceMode, the TargetName and SvcParams within each resource
SvcDomainName and SvcFieldValue parameters within each resource record associate an alternative endpoint for the service with its
record associates an alternative service location with its connection connection parameters.
parameters.
Each protocol scheme that uses SVCB MUST define a protocol mapping Each protocol scheme that uses SVCB MUST define a protocol mapping
that explains how SvcFieldValues are applied for connections of that that explains how SvcParams are applied for connections of that
scheme. Unless specified otherwise by the protocol mapping, clients scheme. Unless specified otherwise by the protocol mapping, clients
MUST ignore SvcFieldValue parameters that they do not recognize. MUST ignore any SvcParam that they do not recognize.
2.6.1. Special handling of "." for SvcDomainName in ServiceForm 2.4.3. SvcPriority
For ServiceForm SVCB RRs, if SvcDomainName has the value "." RRSets are explicitly unordered collections, so the SvcPriority field
(represented in the wire format as a zero-length label), then the is used to impose an ordering on SVCB RRs. SVCB RRs with a smaller
owner name of this record MUST be used as the effective SvcPriority value SHOULD be given preference over RRs with a larger
SvcDomainName. SvcPriority value.
For example, in the following example "svc2.example.net" is the When receiving an RRSet containing multiple SVCB records with the
effective SvcDomainName: same SvcPriority value, clients SHOULD apply a random shuffle within
a priority level to the records before using them, to ensure uniform
load-balancing.
www.example.com. 7200 IN HTTPS 0 svc.example.net. 2.5. Special handling of "." in TargetName
svc.example.net. 7200 IN CNAME svc2.example.net.
svc2.example.net. 7200 IN HTTPS 1 . port=8002 echconfig="..."
svc2.example.net. 300 IN A 192.0.2.2
svc2.example.net. 300 IN AAAA 2001:db8::2
2.6.2. SvcFieldPriority If TargetName has the value "." (represented in the wire format as a
zero-length label), special rules apply.
As RRs within an RRSet are explicitly unordered collections, the 2.5.1. AliasMode
SvcFieldPriority value serves to indicate priority. SVCB RRs with a
smaller SvcFieldPriority value SHOULD be given preference over RRs
with a larger SvcFieldPriority value.
When receiving an RRSet containing multiple SVCB records with the For AliasMode SVCB RRs, a TargetName of "." indicates that the
same SvcFieldPriority value, clients SHOULD apply a random shuffle service is not available or does not exist. This indication is
within a priority level to the records before using them, to ensure advisory: clients encountering this indication MAY ignore it and
uniform load-balancing. attempt to connect without the use of SVCB.
2.5.2. ServiceMode
For ServiceMode SVCB RRs, if TargetName has the value ".", then the
owner name of this record MUST be used as the effective TargetName.
For example, in the following example "svc2.example.net" is the
effective TargetName:
example.com. 7200 IN HTTPS 0 svc.example.net.
svc.example.net. 7200 IN CNAME svc2.example.net.
svc2.example.net. 7200 IN HTTPS 1 . port=8002 echconfig="..."
svc2.example.net. 300 IN A 192.0.2.2
svc2.example.net. 300 IN AAAA 2001:db8::2
3. Client behavior 3. Client behavior
An SVCB-aware client resolves an origin HOST by attempting to A SVCB-aware client selects an endpoint for a service using the
determine the preferred SvcFieldValue and IP addresses for its following procedure:
service, using the following procedure:
1. Issue parallel AAAA/A and SVCB queries for the name HOST. The 1. Let $ADDR_QNAME be the service name. Let $SVCB_QNAME be the
answers for these may or may not include CNAME pointers before service name plus appropriate prefixes for the scheme (see
reaching one or more of these records. Section 2.3).
2. If a SVCB record of AliasForm SvcRecordType is returned for HOST, 2. In parallel, issue AAAA/A queries for $ADDR_QNAME and a SVCB
clients MUST loop back to step 1 replacing HOST with query for $SVCB_QNAME. The answers for these may or may not
SvcDomainName, subject to chain length limits and loop detection include CNAME pointers before reaching one or more of these
heuristics (see Section 3.1). records.
3. If one or more SVCB records of ServiceForm SvcRecordType are 3. If an AliasMode SVCB record is returned for $SVCB_QNAME, clients
returned for HOST, clients should select the highest-priority MUST set $ADDR_QNAME and $SVCB_QNAME to its TargetName (without
option with acceptable parameters, and resolve AAAA and/or A additional prefixes) and loop back to step 2, subject to chain
records for its SvcDomainName if they are not already available. length limits and loop detection heuristics (see Section 3.1).
These are the preferred SvcFieldValue and IP addresses. If the
connection fails, the client MAY try to connect using values from
a lower-priority record. If none of the options succeed, the
client SHOULD connect to the origin server directly.
4. If a SVCB record for HOST does not exist, the received AAAA and/ 4. If one or more ServiceMode records are returned for $SVCB_QNAME,
or A records are the preferred IP addresses and there is no clients SHOULD select the highest-priority compatible record with
SvcFieldValue. acceptable parameters. This TargetName and SvcParams represent
the preferred endpoint. If connection to this endpoint fails,
the client MAY try to connect using values from a lower-priority
record. If all attempts fail, clients SHOULD go to step 5.
This procedure does not rely on any recursive or authoritative server 5. Try to use the endpoint consisting of $ADDR_QNAME, the authority
to comply with this specification or have any awareness of SVCB. endpoint's port number, and no SvcParams.
6. If all of the above connection attempts fail, clients MAY connect
to the authority endpoint.
This procedure does not rely on any recursive or authoritative DNS
server to comply with this specification or have any awareness of
SVCB.
When selecting between AAAA and A records to use, clients may use an When selecting between AAAA and A records to use, clients may use an
approach such as [HappyEyeballsV2]. approach such as Happy Eyeballs [HappyEyeballsV2].
Some important optimizations are discussed in Section 5 to avoid Some important optimizations are discussed in Section 5 to avoid
additional latency in comparison to ordinary AAAA/A lookups. additional latency in comparison to ordinary AAAA/A lookups.
3.1. Handling resolution failures 3.1. Handling resolution failures
If a SVCB query results in a SERVFAIL error, transport error, or If a SVCB query results in a SERVFAIL error, transport error, or
timeout, and DNS exchanges between the client and the recursive timeout, and DNS exchanges between the client and the recursive
resolver are cryptographically protected (e.g. using TLS [RFC7858] or resolver are cryptographically protected (e.g. using TLS [DoT] or
HTTPS [RFC8484]), the client MUST NOT fall back to non-SVCB HTTPS [DoH]), the client SHOULD NOT fall back to $ADDR_QNAME or the
connection establishment. This ensures that an active attacker authority endpoint (steps 5 and 6 above). Otherwise, an active
cannot mount a downgrade attack by denying the user access to the attacker could mount a downgrade attack by denying the user access to
SVCB information. the SvcParams.
A SERVFAIL error can occur if the domain is DNSSEC-signed, the A SERVFAIL error can occur if the domain is DNSSEC-signed, the
recursive resolver is DNSSEC-validating, and the attacker is between recursive resolver is DNSSEC-validating, and the attacker is between
the recursive resolver and the authoritative DNS server. A transport the recursive resolver and the authoritative DNS server. A transport
error or timeout can occur if an active attacker between the client error or timeout can occur if an active attacker between the client
and the recursive resolver is selectively dropping SVCB queries or and the recursive resolver is selectively dropping SVCB queries or
responses, based on their size or other observable patterns. responses, based on their size or other observable patterns.
Similarly, if the client enforces DNSSEC validation on A/AAAA Similarly, if the client enforces DNSSEC validation on A/AAAA
responses, it MUST NOT fall back to non-SVCB connection establishment responses, it SHOULD NOT fall back to steps 5 or 6 if the SVCB
if the SVCB response fails to validate. response fails to validate.
If the client is unable to complete SVCB resolution due to its chain If the client is unable to complete SVCB resolution due to its chain
length limit, the client SHOULD fall back to non-SVCB connection, as length limit, the client SHOULD fall back to the authority endpoint,
if the origin's SVCB record did not exist. as if the origin's SVCB record did not exist.
3.2. Clients using a Proxy 3.2. Clients using a Proxy
Clients using a domain-oriented transport proxy like HTTP CONNECT Clients using a domain-oriented transport proxy like HTTP CONNECT
([RFC7231] Section 4.3.6) or SOCKS5 ([RFC1928]) SHOULD disable SVCB ([RFC7231] Section 4.3.6) or SOCKS5 ([RFC1928]) have the option to
support if performing SVCB queries would violate the client's privacy use named destinations, in which case the client does not perform any
intent. A or AAAA queries for destination domains. If the client is using
named destinations with a proxy that does not provide SVCB query
capability (e.g. through an affiliated DNS resolver), the client
would have to perform SVCB queries though a separate resolver. This
might disclose the client's destinations to an additional party,
creating privacy concerns. If these concerns apply, the client
SHOULD disable SVCB resolution.
If the client can safely perform SVCB queries (e.g. via the proxy or If the client does use SVCB and named destinations, the client SHOULD
an affiliated resolver), the client SHOULD follow the standard SVCB follow the standard SVCB resolution process, selecting the smallest-
resolution process, selecting the highest priority option that is SvcPriority option that is compatible with the client and the proxy.
compatible with the client and the proxy. The client SHOULD provide The client SHOULD provide the final TargetName and port to the proxy,
the final SvcDomainName and port to the proxy, which will perform any which will perform any required A and AAAA lookups.
required A and AAAA lookups.
Providing the proxy with the final SvcDomainName has several Providing the proxy with the final TargetName has several benefits:
benefits:
o It allows the client to use the SvcFieldValue, if present, which o It allows the client to use the SvcParams, if present, which is
is only usable with a specific SvcDomainName. The SvcFieldValue only usable with a specific TargetName. The SvcParams may include
may include information that enhances performance (e.g. alpn) and information that enhances performance (e.g. alpn) and privacy
privacy (e.g. echconfig). (e.g. echconfig).
o It allows the origin to delegate the apex domain. o It allows the service to delegate the apex domain.
o It allows the proxy to select between IPv4 and IPv6 addresses for o It allows the proxy to select between IPv4 and IPv6 addresses for
the server according to its configuration, and receive addresses the server according to its configuration, and receive addresses
based on its network geolocation. based on its network geolocation.
4. DNS Server Behavior 4. DNS Server Behavior
4.1. Authoritative servers 4.1. Authoritative servers
When replying to a SVCB query, authoritative DNS servers SHOULD When replying to a SVCB query, authoritative DNS servers SHOULD
return A, AAAA, and SVCB records (as well as any relevant CNAME or return A, AAAA, and SVCB records in the Additional Section for any
[DNAME] records) in the Additional Section for any in-bailiwick in-bailiwick TargetNames. If the zone is signed, the server SHOULD
SvcDomainNames. also include positive or negative DNSSEC responses for these records
in the Additional section.
4.2. Recursive resolvers 4.2. Recursive resolvers
Recursive resolvers that are aware of SVCB SHOULD ensure that the Recursive resolvers that are aware of SVCB SHOULD help the client to
client can execute the procedure in Section 3 without issuing a execute the procedure in Section 3 with minimum overall latency, by
second round of queries, by incorporating all the necessary incorporating additional useful information into the response. For
information into a single response. For the initial SVCB record the initial SVCB record query, this is just the normal response
query, this is just the normal response construction process (i.e. construction process (i.e. unknown RR type resolution under
unknown RR type resolution under [RFC3597]). For followup [RFC3597]). For followup resolutions performed during this
resolutions performed during this procedure, we define incorporation procedure, we define incorporation as adding all useful RRs from the
as adding all Answer and Additional RRs to the Additional section, response to the Additional section without altering the response
and all Authority RRs to the Authority section, without altering the code.
response code.
Upon receiving a SVCB query, recursive resolvers SHOULD start with Upon receiving a SVCB query, recursive resolvers SHOULD start with
the standard resolution procedure, and then follow this procedure to the standard resolution procedure, and then follow this procedure to
construct the full response to the stub resolver: construct the full response to the stub resolver:
1. Incorporate the results of SVCB resolution. If the chain length 1. Incorporate the results of SVCB resolution. If the chain length
limit has been reached, terminate successfully (i.e. a NOERROR limit has been reached, terminate successfully (i.e. a NOERROR
response). response).
2. If any of the resolved SVCB records are in AliasForm, choose an 2. If any of the resolved SVCB records are in AliasMode, choose one
AliasForm record at random, and resolve SVCB, A, and AAAA records of them at random, and resolve SVCB, A, and AAAA records for its
for its SvcDomainName. TargetName.
* If any SVCB records are resolved, go to step 1. * If any SVCB records are resolved, go to step 1.
* Otherwise, incorporate the results of A and AAAA resolution, * Otherwise, incorporate the results of A and AAAA resolution,
and terminate. and terminate.
3. All the resolved SVCB records are in ServiceForm. Resolve A and 3. All the resolved SVCB records are in ServiceMode. Resolve A and
AAAA queries for each SvcDomainName (or for the owner name if AAAA queries for each TargetName (or for the owner name if
SvcDomainName is "."), incorporate all the results, and TargetName is "."), incorporate all the results, and terminate.
terminate.
In this procedure, "resolve" means the resolver's ordinary recursive In this procedure, "resolve" means the resolver's ordinary recursive
resolution procedure, as if processing a query for that RRSet. This resolution procedure, as if processing a query for that RRSet. This
includes following any aliases that the resolver would ordinarily includes following any aliases that the resolver would ordinarily
follow (e.g. CNAME, [DNAME]). follow (e.g. CNAME, DNAME [DNAME]).
See Section 5.2 for possible optimizations of this procedure.
4.3. General requirements 4.3. General requirements
All DNS servers SHOULD treat the SvcFieldValue portion of the SVCB RR Recursive resolvers SHOULD treat the SvcParams portion of the SVCB RR
as opaque and SHOULD NOT try to alter their behavior based on its as opaque and SHOULD NOT try to alter their behavior based on its
contents. contents.
When responding to a query that includes the DNSSEC OK bit When responding to a query that includes the DNSSEC OK bit
([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers ([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers
MUST accompany each RRSet in the Additional section with the same MUST accompany each RRSet in the Additional section with the same
DNSSEC-related records that they would send when providing that RRSet DNSSEC-related records that they would send when providing that RRSet
as an Answer (e.g. RRSIG, NSEC, NSEC3). as an Answer (e.g. RRSIG, NSEC, NSEC3).
5. Performance optimizations 5. Performance optimizations
skipping to change at page 17, line 12 skipping to change at page 17, line 25
SHOULD wait for 50 milliseconds before starting optimistic pre- SHOULD wait for 50 milliseconds before starting optimistic pre-
connection, as per the guidance in [HappyEyeballsV2]. connection, as per the guidance in [HappyEyeballsV2].
An SVCB record is consistent with a connection if the client would An SVCB record is consistent with a connection if the client would
attempt an equivalent connection when making use of that record. If attempt an equivalent connection when making use of that record. If
a SVCB record is consistent with an active or in-progress connection a SVCB record is consistent with an active or in-progress connection
C, the client MAY prefer that record and use C as its connection. C, the client MAY prefer that record and use C as its connection.
For example, suppose the client receives this SVCB RRSet for a For example, suppose the client receives this SVCB RRSet for a
protocol that uses TLS over TCP: protocol that uses TLS over TCP:
_1234._bar.example.com. 300 IN SVCB 1 svc1.example.net ( _1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. (
echconfig="111..." ipv6hint=2001:db8::1 port=1234 ... ) echconfig="111..." ipv6hint=2001:db8::1 port=1234 ... )
SVCB 2 svc2.example.net ( SVCB 2 svc2.example.net. (
echconfig="222..." ipv6hint=2001:db8::2 port=1234 ... ) echconfig="222..." ipv6hint=2001:db8::2 port=1234 ... )
If the client has an in-progress TCP connection to If the client has an in-progress TCP connection to
"[2001:db8::2]:1234", it MAY proceed with TLS on that connection "[2001:db8::2]:1234", it MAY proceed with TLS on that connection
using "echconfig="222..."", even though the other record in the RRSet using "echconfig="222..."", even though the other record in the RRSet
has higher priority. has higher priority.
If none of the SVCB records are consistent with any active or in- If none of the SVCB records are consistent with any active or in-
progress connection, clients must proceed as described in Step 3 of progress connection, clients must proceed as described in Step 3 of
the procedure in Section 3. the procedure in Section 3.
5.2. Generating and using incomplete responses 5.2. Generating and using incomplete responses
When following the procedure in Section 4.2, recursive resolvers MAY When following the procedure in Section 4.2, recursive resolvers MAY
terminate the procedure early and produce a reply that omits some of terminate the procedure early and produce a reply that omits some of
the associated RRSets. This is REQUIRED when the chain length limit the associated RRSets. This is REQUIRED when the chain length limit
is reached (Section 4.2 step 1), but might also be appropriate when is reached (Section 4.2 step 1), but might also be appropriate when
the maximum response size is reached, or when responding before fully the maximum response size is reached, or when responding before fully
chasing dependencies would improve performance. When omitting chasing dependencies would improve performance. When omitting
certain RRSets, recursive resolvers SHOULD prioritize information certain RRSets, recursive resolvers SHOULD prioritize information for
from higher priority ServiceForm records over lower priority smaller-SvcPriority records.
ServiceForm records.
As discussed in Section 3, clients MUST be able to fetch additional As discussed in Section 3, clients MUST be able to fetch additional
information that is required to use a SVCB record, if it is not information that is required to use a SVCB record, if it is not
included in the initial response. As a performance optimization, if included in the initial response. As a performance optimization, if
some of the SVCB records in the response can be used without some of the SVCB records in the response can be used without
requiring additional DNS queries, the client MAY prefer those requiring additional DNS queries, the client MAY prefer those
records, regardless of their priorities. records, regardless of their priorities.
5.3. Structuring zones for performance 5.3. Structuring zones for performance
To avoid a delay for clients using a nonconforming recursive To avoid a delay for clients using a nonconforming recursive
resolver, domain owners SHOULD use a single SVCB record whose resolver, domain owners SHOULD minimize the use of AliasMode records,
SvcDomainName is "." if possible. This will ensure that the required and choose TargetName to be a domain for which the client will have
address records are already present in the client's DNS cache as part already issued address queries (see Section 3). For
of the responses to the address queries that were issued in parallel. foo://foo.example.com:8080, this might look like:
; Origin zone
foo.example.com. 3600 IN CNAME foosvc.example.net.
_8080._foo.foo.example.com. 3600 IN CNAME foosvc.example.net.
; Service provider zone
foosvc.example.net. 3600 IN SVCB 1 . key65333=...
foosvc.example.net. 300 IN AAAA 2001:db8::1
Domain owners SHOULD avoid using a SvcDomainName that is below a
DNAME, as this is likely unnecessary and makes responses slower and
larger.
6. Initial SvcParamKeys 6. Initial SvcParamKeys
A few initial SvcParamKeys are defined here. These keys are useful A few initial SvcParamKeys are defined here. These keys are useful
for HTTPS, and most are applicable to other protocols as well. for HTTPS, and most are applicable to other protocols as well.
6.1. "alpn" and "no-default-alpn" 6.1. "alpn" and "no-default-alpn"
The "alpn" and "no-default-alpn" SvcParamKeys together indicate the The "alpn" and "no-default-alpn" SvcParamKeys together indicate the
set of Application Layer Protocol Negotation (ALPN) protocol set of Application Layer Protocol Negotation (ALPN) protocol
identifiers [ALPN] and associated transport protocols supported by identifiers [ALPN] and associated transport protocols supported by
this service endpoint. this service endpoint.
As with [AltSvc], the ALPN protocol identifier is used to identify As with Alt-Svc [AltSvc], the ALPN protocol identifier is used to
the application protocol and associated suite of protocols supported identify the application protocol and associated suite of protocols
by the endpoint (the "protocol suite"). Clients filter the set of supported by the endpoint (the "protocol suite"). Clients filter the
ALPN identifiers to match the protocol suites they support, and this set of ALPN identifiers to match the protocol suites they support,
informs the underlying transport protocol used (such as QUIC-over-UDP and this informs the underlying transport protocol used (such as
or TLS-over-TCP). QUIC-over-UDP or TLS-over-TCP).
ALPNs are identified by their registered "Identification Sequence" ALPNs are identified by their registered "Identification Sequence"
(alpn-id), which is a sequence of 1-255 octets. ("alpn-id"), which is a sequence of 1-255 octets.
alpn-id = 1*255(OCTET)
The presentation value of "alpn" is a comma-separated list of one or
more "alpn-id"s. Any commas present in the protocol-id are escaped
by a backslash:
escaped-octet = %x00-2b / "\," / %x2d-5b / "\\" / %x5D-FF alpn-id = 1*255OCTET
escaped-id = 1*(escaped-octet) "alpn" is a multi-valued SvcParamKey. Each decoded value in the
alpn-value = escaped-id *("," escaped-id) "alpn" value list SHALL be an "alpn-id". The value list MUST NOT be
empty.
The wire format value for "alpn" consists of at least one ALPN The wire format value for "alpn" consists of at least one "alpn-id"
identifier ("alpn-id") prefixed by its length as a single octet, and prefixed by its length as a single octet, and these length-value
these length-value pairs are concatenated to form the SvcParamValue. pairs are concatenated to form the SvcParamValue. These pairs MUST
These pairs MUST exactly fill the SvcParamValue; otherwise, the exactly fill the SvcParamValue; otherwise, the SvcParamValue is
SvcParamValue is malformed. malformed.
For "no-default-alpn", the presentation and wire format values MUST For "no-default-alpn", the presentation and wire format values MUST
be empty. be empty.
Each scheme that uses this SvcParamKey defines a "default set" of Each scheme that uses this SvcParamKey defines a "default set" of
supported ALPNs, which SHOULD NOT be empty. To determine the set of supported ALPNs, which SHOULD NOT be empty. To determine the set of
protocol suites supported by an endpoint (the "ALPN set"), the client protocol suites supported by an endpoint (the "SVCB ALPN set"), the
parses the set of ALPN identifiers in the "alpn" parameter, and then client adds the default set to the list of "alpn-id"s unless the "no-
adds the default set unless the "no-default-alpn" SvcParamKey is default-alpn" SvcParamKey is present. The presence of an ALPN
present. The presence of a value in the alpn set indicates that this protocol in the SVCB ALPN set indicates that this service endpoint,
service endpoint, described by SvcDomainName and the other parameters described by TargetName and the other parameters (e.g. "port") offers
(e.g. "port") offers service with the protocol suite associated with service with the protocol suite associated with this ALPN protocol.
the ALPN ID.
ALPN IDs that do not uniquely identify a protocol suite (e.g. an ID ALPN protocol names that do not uniquely identify a protocol suite
that can be used with both TLS and DTLS) are not compatible with this (e.g. an Identification Sequence that can be used with both TLS and
SvcParamKey and MUST NOT be included in the ALPN set. DTLS) are not compatible with this SvcParamKey and MUST NOT be
included in the SVCB ALPN set.
To establish a connection to the endpoint, clients MUST
1. Let SVCB-ALPN-Intersection be the set of protocols in the SVCB
ALPN set that the client supports.
2. Let Intersection-Transports be the set of transports (e.g. TLS,
DTLS, QUIC) implied by the protocols in SVCB-ALPN-Intersection.
3. For each transport in Intersection-Transports, construct a
ProtocolNameList containing the Identification Sequences of all
the client's supported ALPN protocols for that transport, without
regard to the SVCB ALPN set.
For example, if the SVCB ALPN set is ["http/1.1", "h3"], and the
client supports HTTP/1.1, HTTP/2, and HTTP/3, the client could
attempt to connect using TLS over TCP with a ProtocolNameList of
["http/1.1", "h2"], and could also attempt a connection using QUIC,
with a ProtocolNameList of ["h3"].
Once the client has constructed a ClientHello, protocol negotiation
in that handshake proceeds as specified in [ALPN], without regard to
the SVCB ALPN set.
With this procedure in place, an attacker who can modify DNS and
network traffic can prevent a successful transport connection, but
cannot otherwise interfere with ALPN protocol selection. This
procedure also ensures that each ProtocolNameList includes at least
one protocol from the SVCB ALPN set.
Clients SHOULD NOT attempt connection to a service endpoint whose Clients SHOULD NOT attempt connection to a service endpoint whose
ALPN set does not contain any compatible protocol suites. To ensure SVCB ALPN set does not contain any supported protocols. To ensure
consistency of behavior, clients MAY reject the entire SVCB RRSet and consistency of behavior, clients MAY reject the entire SVCB RRSet and
fall back to basic connection establishment if all of the RRs fall back to basic connection establishment if all of the RRs
indicate "no-default-alpn", even if connection could have succeeded indicate "no-default-alpn", even if connection could have succeeded
using a non-default alpn. using a non-default alpn.
For compatibility with clients that require default transports, zone For compatibility with clients that require default transports, zone
operators SHOULD ensure that at least one RR in each RRSet supports operators SHOULD ensure that at least one RR in each RRSet supports
the default transports. the default transports.
Clients MUST include an "application_layer_protocol_negotiation"
extension in their ClientHello with a ProtocolNameList that includes
at least one ID from the ALPN set. Clients SHOULD also include any
other values that they support and could negotiate on that connection
with equivalent or better security properties. For example, if the
ALPN set only contains "http/1.1", the client could include
"http/1.1" and "h2" in the ProtocolNameList.
Once the client has formulated the ClientHello, protocol negotiation
on that connection proceeds as specified in [ALPN], without regard to
the SVCB ALPN set. To preserve the security guarantees of this
process, clients MUST consolidate all compatible ALPN IDs into a
single ProtocolNameList.
6.2. "port" 6.2. "port"
The "port" SvcParamKey defines the TCP or UDP port that should be The "port" SvcParamKey defines the TCP or UDP port that should be
used to contact this alternative service. If this key is not used to reach this alternative endpoint. If this key is not present,
present, clients SHALL use the origin server's port number. clients SHALL use the authority endpoint's port number.
The presentation format of the SvcParamValue is a numeric value The presentation "value" of the SvcParamValue is a single decimal
between 0 and 65535 inclusive. Any other values (e.g. the empty integer between 0 and 65535 in ASCII. Any other "value" (e.g. an
value) are syntax errors. empty value) is a syntax error. To enable simpler parsing, this
SvcParam MUST NOT contain escape sequences.
The wire format of the SvcParamValue is the corresponding 2 octet The wire format of the SvcParamValue is the corresponding 2 octet
numeric value in network byte order. numeric value in network byte order.
If a port-restricting firewall is in place between some client and If a port-restricting firewall is in place between some client and
the service endpoint, changing the port number might cause that the service endpoint, changing the port number might cause that
client to lose access to the service, so operators should exercise client to lose access to the service, so operators should exercise
caution when using this SvcParamKey to specify a non-default port. caution when using this SvcParamKey to specify a non-default port.
6.3. "echconfig" 6.3. "echconfig"
The SvcParamKey to enable Encrypted ClientHello (ECH) is "echconfig". The SvcParamKey to enable Encrypted ClientHello (ECH) is "echconfig".
Its value is defined in Section 8. It is applicable to most TLS- Its value is defined in Section 8. It is applicable to most TLS-
based protocols. based protocols.
When publishing a record containing an "echconfig" parameter, the When publishing a record containing an "echconfig" parameter, the
publisher MUST ensure that all IP addresses of SvcDomainName publisher MUST ensure that all IP addresses of TargetName correspond
correspond to servers that have access to the corresponding private to servers that have access to the corresponding private key or are
key or are authoritative for the public name. (See Section 7.2.2 of authoritative for the public name. (See Section 7.2.2 of [ECH] for
[ECH] for more details about the public name.) This yields an more details about the public name.) This yields an anonymity set of
anonymity set of cardinality equal to the number of ECH-enabled cardinality equal to the number of ECH-enabled server domains
server domains supported by a given client-facing server. Thus, even supported by a given client-facing server. Thus, even with an
with an encrypted ClientHello, an attacker who can enumerate the set encrypted ClientHello, an attacker who can enumerate the set of ECH-
of ECH-enabled domains supported by a client-facing server can guess enabled domains supported by a client-facing server can guess the
the correct SNI with probability at least 1/K, where K is the size of correct SNI with probability at least 1/K, where K is the size of
this ECH-enabled server anonymity set. This probability may be this ECH-enabled server anonymity set. This probability may be
increased via traffic analysis or other mechanisms. increased via traffic analysis or other mechanisms.
6.4. "ipv4hint" and "ipv6hint" 6.4. "ipv4hint" and "ipv6hint"
The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients
MAY use to reach the service. If A and AAAA records for MAY use to reach the service. If A and AAAA records for TargetName
SvcDomainName are locally available, the client SHOULD ignore these are locally available, the client SHOULD ignore these hints.
hints. Otherwise, clients SHOULD perform A and/or AAAA queries for Otherwise, clients SHOULD perform A and/or AAAA queries for
SvcDomainName as in Section 3, and clients SHOULD use the IP address TargetName as in Section 3, and clients SHOULD use the IP address in
in those responses for future connections. Clients MAY opt to those responses for future connections. Clients MAY opt to terminate
terminate any connections using the addresses in hints and instead any connections using the addresses in hints and instead switch to
switch to the addresses in response to the SvcDomainName query. the addresses in response to the TargetName query. Failure to use A
Failure to use A and/or AAAA response addresses could negatively and/or AAAA response addresses could negatively impact load balancing
impact load balancing or other geo-aware features and thereby degrade or other geo-aware features and thereby degrade client performance.
client performance.
Each decoded value in the value list SHALL be an IP address of the
appropriate family in standard textual format [RFC5952]. To enable
simpler parsing, this SvcParam MUST NOT contain escape sequences.
The wire format for each parameter is a sequence of IP addresses in The wire format for each parameter is a sequence of IP addresses in
network byte order. Like an A or AAAA RRSet, the list of addresses network byte order. Like an A or AAAA RRSet, the list of addresses
represents an unordered collection, and clients SHOULD pick addresses represents an unordered collection, and clients SHOULD pick addresses
to use in a random order. An empty list of addresses is invalid. to use in a random order. An empty list of addresses is invalid.
When selecting between IPv4 and IPv6 addresses to use, clients may When selecting between IPv4 and IPv6 addresses to use, clients may
use an approach such as [HappyEyeballsV2]. When only "ipv4hint" is use an approach such as Happy Eyeballs [HappyEyeballsV2]. When only
present, IPv6-only clients may synthesize IPv6 addresses as specified "ipv4hint" is present, IPv6-only clients may synthesize IPv6
in [RFC7050] or ignore the "ipv4hint" key and wait for AAAA addresses as specified in [RFC7050] or ignore the "ipv4hint" key and
resolution (Section 3). Recursive resolvers MUST NOT perform DNS64 wait for AAAA resolution (Section 3). Recursive resolvers MUST NOT
([RFC6147]) on parameters within a SVCB record. For best perform DNS64 ([RFC6147]) on parameters within a SVCB record. For
performance, server operators SHOULD include an "ipv6hint" parameter best performance, server operators SHOULD include an "ipv6hint"
whenever they include an "ipv4hint" parameter. parameter whenever they include an "ipv4hint" parameter.
The presentation format for each parameter is a comma-separated list
of IP addresses in standard textual format [RFC5952].
These parameters are intended to minimize additional connection These parameters are intended to minimize additional connection
latency when a recursive resolver is not compliant with the latency when a recursive resolver is not compliant with the
requirements in Section 4, and SHOULD NOT be included if most clients requirements in Section 4, and SHOULD NOT be included if most clients
are using compliant recursive resolvers. When SvcDomainName is ".", are using compliant recursive resolvers. When TargetName is the
origin hostname or the owner name (which can be written as "."),
server operators SHOULD NOT include these hints, because they are server operators SHOULD NOT include these hints, because they are
unlikely to convey any performance benefit. unlikely to convey any performance benefit.
6.5. "mandatory"
In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the
RR will not function correctly for clients that ignore this
SvcParamKey. Each SVCB protocol mapping SHOULD specify a set of keys
that are "automatically mandatory", i.e. mandatory if they are
present in an RR. The SvcParamKey "mandatory" is used to indicate
any mandatory keys for this RR, in addition to any automatically
mandatory keys that are present.
A ServiceMode RR is considered "compatible" with a client if the
client implements support for all its mandatory keys. If the SVCB
RRSet contains no compatible RRs, the client will generally act as if
the RRSet is empty.
In presentation format, "mandatory" contains a list of one or more
valid SvcParamKeys, either by their registered name or in the
unknown-key format (Section 2.1). Keys MAY appear in any order, but
MUST NOT appear more than once. Any listed keys MUST also appear in
the SvcParams. For example, the following is a valid list of
SvcParams:
echconfig=... key65333=ex1 key65444=ex2 mandatory=key65444,echconfig
In wire format, the keys are represented by their numeric values in
network byte order, concatenated in ascending order.
This SvcParamKey is always automatically mandatory, and MUST NOT
appear in its own value list. Other automatically mandatory keys
SHOULD NOT appear in the list either. (Including them wastes space
and otherwise has no effect.)
7. Using SVCB with HTTPS and HTTP 7. Using SVCB with HTTPS and HTTP
Use of any protocol with SVCB requires a protocol-specific mapping Use of any protocol with SVCB requires a protocol-specific mapping
specification. This section specifies the mapping for HTTPS and specification. This section specifies the mapping for HTTPS and
HTTP. HTTP.
To enable special handling for the HTTPS and HTTP use-cases, the To enable special handling for the HTTPS and HTTP use-cases, the
HTTPS RR type is defined as a SVCB-compatible RR type, specific to HTTPS RR type is defined as a SVCB-compatible RR type, specific to
the https and http schemes. Clients MUST NOT perform SVCB queries or the https and http schemes. Clients MUST NOT perform SVCB queries or
accept SVCB responses for "https" or "http" schemes. accept SVCB responses for "https" or "http" schemes.
The HTTPS RR wire format and presentation format are identical to The HTTPS RR wire format and presentation format are identical to
SVCB, and both share the SvcParamKey registry. SVCB semantics apply SVCB, and both share the SvcParamKey registry. SVCB semantics apply
equally to HTTPS RRs unless specified otherwise. equally to HTTPS RRs unless specified otherwise. The presentation
format of the record is:
Name TTL IN HTTPS SvcPriority TargetName SvcParams
As with SVCB, the record is defined specifically within the Internet
("IN") Class [RFC1035].
All the SvcParamKeys defined in Section 6 are permitted for use in All the SvcParamKeys defined in Section 6 are permitted for use in
HTTPS RRs. The default set of ALPN IDs is the single value HTTPS RRs. The default set of ALPN IDs is the single value
"http/1.1". "http/1.1". The "automatically mandatory" keys (Section 6.5) are
"port", "alpn", and "no-default-alpn".
The presence of an HTTPS RR for an origin also indicates that all The presence of an HTTPS RR for an origin also indicates that all
HTTP resources are available over HTTPS, as discussed in Section 7.5. HTTP resources are available over HTTPS, as discussed in Section 7.5.
This allows HTTPS RRs to apply to pre-existing "http" scheme URLs, This allows HTTPS RRs to apply to pre-existing "http" scheme URLs,
while ensuring that the client uses a secure and authenticated HTTPS while ensuring that the client uses a secure and authenticated HTTPS
connection. connection.
The HTTPS RR parallels the concepts introduced in the HTTP The HTTPS RR parallels the concepts introduced in the HTTP
Alternative Services proposed standard [AltSvc]. Clients and servers Alternative Services proposed standard [AltSvc]. Clients and servers
that implement HTTPS RRs are NOT REQUIRED to implement Alt-Svc. that implement HTTPS RRs are not required to implement Alt-Svc.
7.1. Owner names for HTTPS RRs 7.1. Owner names for HTTPS RRs
The HTTPS RR uses Port Prefix Naming (Section 2.3), with one The HTTPS RR uses Port Prefix Naming (Section 2.3), with one
modification: if the scheme is "https" and the port is 443, then the modification: if the scheme is "https" and the port is 443, then the
client's original QNAME is equal to the origin hostname, without any client's original QNAME is equal to the service name (i.e. the
prefix labels. origin's hostname), without any prefix labels.
By removing the [Attrleaf] labels used in SVCB, this construction By removing the Attrleaf labels [Attrleaf] used in SVCB, this
enables offline DNSSEC signing of wildcard domains, which are construction enables offline DNSSEC signing of wildcard domains,
commonly used with HTTPS. Reusing the origin hostname also allows which are commonly used with HTTPS. Reusing the service name also
the targets of existing CNAME chains (e.g. CDN hosts) to start allows the targets of existing CNAME chains (e.g. CDN hosts) to
returning HTTPS RR responses without requiring origin domains to start returning HTTPS RR responses without requiring origin domains
configure and maintain an additional delegation. to configure and maintain an additional delegation.
Following of HTTPS RR AliasForm and CNAME aliases is unchanged from Following of HTTPS AliasMode RRs and CNAME aliases is unchanged from
SVCB. SVCB.
Clients always convert "http" URLs to "https" before performing an Clients always convert "http" URLs to "https" before performing an
HTTPS RR query using the process described in Section 7.5, so domain HTTPS RR query using the process described in Section 7.5, so domain
owners MUST NOT publish HTTPS RRs with a prefix of "_http". owners MUST NOT publish HTTPS RRs with a prefix of "_http".
Note that none of these forms alter the HTTPS origin or authority. Note that none of these forms alter the HTTPS origin or authority.
For example, clients MUST continue to validate TLS certificate For example, clients MUST continue to validate TLS certificate
hostnames based on the origin host. hostnames based on the origin.
7.2. Relationship to Alt-Svc 7.2. Relationship to Alt-Svc
Publishing a ServiceForm HTTPS RR in DNS is intended to be similar to Publishing a ServiceMode HTTPS RR in DNS is intended to be similar to
transmitting an Alt-Svc field value over HTTPS, and receiving an transmitting an Alt-Svc field value over HTTPS, and receiving an
HTTPS RR is intended to be similar to receiving that field value over HTTPS RR is intended to be similar to receiving that field value over
HTTPS. However, there are some differences in the intended client HTTPS. However, there are some differences in the intended client
and server behavior. and server behavior.
7.2.1. ALPN usage 7.2.1. ALPN usage
Unlike Alt-Svc Field Values, HTTPS RRs can contain multiple ALPN IDs, Unlike Alt-Svc Field Values, HTTPS RRs can contain multiple ALPN IDs,
and clients are encouraged to offer additional ALPNs that they and clients are encouraged to offer additional ALPNs that they
support (subject to security constraints). support (subject to security constraints).
skipping to change at page 23, line 26 skipping to change at page 25, line 7
records beyond the stated TTL, so server operators cannot rely on records beyond the stated TTL, so server operators cannot rely on
HTTPS RRs expiring on time. Shortening the TTL to compensate for HTTPS RRs expiring on time. Shortening the TTL to compensate for
incorrect caching is NOT RECOMMENDED, as this practice impairs the incorrect caching is NOT RECOMMENDED, as this practice impairs the
performance of correctly functioning caches and does not guarantee performance of correctly functioning caches and does not guarantee
faster expiration from incorrect caches. Instead, server operators faster expiration from incorrect caches. Instead, server operators
SHOULD maintain compatibility with expired records until they observe SHOULD maintain compatibility with expired records until they observe
that nearly all connections have migrated to the new configuration. that nearly all connections have migrated to the new configuration.
Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc
Field Value specifically to the client. When using an HTTPS RR, Field Value specifically to the client. When using an HTTPS RR,
groups of clients will necessarily receive the same SvcFieldValue. groups of clients will necessarily receive the same SvcParams.
Therefore, HTTPS RRs are not suitable for uses that require single- Therefore, HTTPS RRs are not suitable for uses that require single-
client granularity. client granularity.
7.3. Interaction with Alt-Svc 7.3. Interaction with Alt-Svc
Clients that do not implement support for Encrypted ClientHello MAY Clients that do not implement support for Encrypted ClientHello MAY
skip the HTTPS RR query if a usable Alt-Svc value is available in the skip the HTTPS RR query if a usable Alt-Svc value is available in the
local cache. If Alt-Svc connection fails, these clients SHOULD fall local cache. If Alt-Svc connection fails, these clients SHOULD fall
back to the HTTPS RR client connection procedure (Section 3). back to the HTTPS RR client connection procedure (Section 3).
skipping to change at page 23, line 50 skipping to change at page 25, line 31
This specification does not alter the DNS queries performed when This specification does not alter the DNS queries performed when
connecting to an Alt-Svc hostname (typically A and/or AAAA only). connecting to an Alt-Svc hostname (typically A and/or AAAA only).
7.4. Requiring Server Name Indication 7.4. Requiring Server Name Indication
Clients MUST NOT use an HTTPS RR response unless the client supports Clients MUST NOT use an HTTPS RR response unless the client supports
TLS Server Name Indication (SNI) and indicate the origin name when TLS Server Name Indication (SNI) and indicate the origin name when
negotiating TLS. This supports the conservation of IP addresses. negotiating TLS. This supports the conservation of IP addresses.
Note that the TLS SNI (and also the HTTP "Host" or ":authority") will Note that the TLS SNI (and also the HTTP "Host" or ":authority") will
indicate the origin, not the SvcDomainName. indicate the origin, not the TargetName.
7.5. HTTP Strict Transport Security 7.5. HTTP Strict Transport Security
By publishing an HTTPS RR, the server operator indicates that all By publishing a usable HTTPS RR, the server operator indicates that
useful HTTP resources on that origin are reachable over HTTPS, all useful HTTP resources on that origin are reachable over HTTPS,
similar to HTTP Strict Transport Security [HSTS]. When an HTTPS RR similar to HTTP Strict Transport Security [HSTS].
is present for an origin, all "http" scheme requests for that origin
SHOULD logically be redirected to "https".
Prior to making an "http" scheme request, the client SHOULD perform a Prior to making an "http" scheme request, the client SHOULD perform a
lookup to determine if any HTTPS RRs exist for that origin. To do lookup to determine if any HTTPS RRs exist for that origin. To do
so, the client SHOULD construct a corresponding "https" URL as so, the client SHOULD construct a corresponding "https" URL as
follows: follows:
1. Replace the "http" scheme with "https". 1. Replace the "http" scheme with "https".
2. If the "http" URL explicitly specifies port 80, specify port 443. 2. If the "http" URL explicitly specifies port 80, specify port 443.
3. Do not alter any other aspect of the URL. 3. Do not alter any other aspect of the URL.
This construction is equivalent to Section 8.3 of [HSTS], point 5. This construction is equivalent to Section 8.3 of [HSTS], point 5.
If an HTTPS RR query for this "https" URL returns any HTTPS RRs If an HTTPS RR query for this "https" URL returns any AliasMode HTTPS
(AliasForm or ServiceForm), the client SHOULD act as if it has RRs, or any compatible ServiceMode HTTPS RRs (see Section 6.5), the
received an HTTP "307 Temporary Redirect" redirect to this "https" client SHOULD act as if it has received an HTTP "307 Temporary
URL. Because HTTPS RRs are received over an often insecure channel Redirect" redirect to this "https" URL. (Receipt of an incompatible
(DNS), clients MUST NOT place any more trust in this signal than if ServiceMode RR does not trigger the redirect behavior.) Because
they had received a 307 redirect over cleartext HTTP. HTTPS RRs are received over an often insecure channel (DNS), clients
MUST NOT place any more trust in this signal than if they had
received a 307 redirect over cleartext HTTP.
When making an "https" scheme request to an origin with an HTTPS RR, When making an "https" scheme request to an origin with an HTTPS RR,
either directly or via the above redirect, the client SHOULD either directly or via the above redirect, the client SHOULD
terminate the connection if there are any errors with the underlying terminate the connection if there are any errors with the underlying
secure transport, such as errors in certificate validation. This secure transport, such as errors in certificate validation. This
aligns with Section 8.4 and Section 12.1 of [HSTS]. aligns with Section 8.4 and Section 12.1 of [HSTS].
7.6. HTTP-based protocols 7.6. HTTP-based protocols
We define an "HTTP-based protocol" as one that involves connecting to We define an "HTTP-based protocol" as one that involves connecting to
an "http:" or "https:" URL. When implementing an HTTP-based an "http:" or "https:" URL. When implementing an HTTP-based
protocol, clients that use HTTPS RRs for HTTP SHOULD also use it for protocol, clients that use HTTPS RRs for HTTP SHOULD also use it for
this URL. For example, clients that support HTTPS RRs and implement this URL. For example, clients that support HTTPS RRs and implement
the altered [WebSocket] opening handshake from [FETCH] SHOULD use the altered WebSocket [WebSocket] opening handshake from the W3C
HTTPS RRs for the "requestURL". Fetch specification [FETCH] SHOULD use HTTPS RRs for the
"requestURL".
An HTTP-based protocol MAY define its own SVCB mapping. Such An HTTP-based protocol MAY define its own SVCB mapping. Such
mappings MAY be defined to take precedence over HTTPS RRs. mappings MAY be defined to take precedence over HTTPS RRs.
8. SVCB/HTTPS RR parameter for ECH configuration 8. SVCB/HTTPS RR parameter for ECH configuration
The SVCB "echconfig" parameter is defined for conveying the ECH The SVCB "echconfig" parameter is defined for conveying the ECH
configuration of an alternative service. In wire format, the value configuration of an alternative endpoint. In wire format, the value
of the parameter is an ECHConfigs vector [ECH], including the of the parameter is an ECHConfigs vector [ECH], including the
redundant length prefix. In presentation format, the value is redundant length prefix. In presentation format, the value is a
encoded in [base64]. single ECHConfigs encoded in Base64 [base64]. Base64 is used here to
simplify integration with TLS server software. To enable simpler
parsing, this SvcParam MUST NOT contain escape sequences.
When ECH is in use, the TLS ClientHello is divided into an When ECH is in use, the TLS ClientHello is divided into an
unencrypted "outer" and an encrypted "inner" ClientHello. The outer unencrypted "outer" and an encrypted "inner" ClientHello. The outer
ClientHello is an implementation detail of ECH, and its contents are ClientHello is an implementation detail of ECH, and its contents are
controlled by the ECHConfig in accordance with [ECH]. The inner controlled by the ECHConfig in accordance with [ECH]. The inner
ClientHello is used for establishing a connection to the service, so ClientHello is used for establishing a connection to the service, so
its contents may be influenced by other SVCB parameters. For its contents may be influenced by other SVCB parameters. For
example, the requirements on the ProtocolNameList in Section 6.1 example, the requirements on the ProtocolNameList in Section 6.1
apply only to the inner ClientHello. Similarly, it is the inner apply only to the inner ClientHello. Similarly, it is the inner
ClientHello whose Server Name Indication identifies the origin. ClientHello whose Server Name Indication identifies the desired
service.
8.1. Client behavior 8.1. Client behavior
The general client behavior specified in Section 3 permits clients to The general client behavior specified in Section 3 permits clients to
retry connection with a less preferred alternative if the preferred retry connection with a less preferred alternative if the preferred
option fails, including falling back to a direct connection if all option fails, including falling back to a direct connection if all
SVCB options fail. This behavior is not suitable for ECH, because SVCB options fail. This behavior is not suitable for ECH, because
fallback would negate the privacy benefits of ECH. Accordingly, ECH- fallback would negate the privacy benefits of ECH. Accordingly, ECH-
capable clients SHALL implement the following behavior for connection capable clients SHALL implement the following behavior for connection
establishment. establishment:
1. Perform connection establishment using HTTPS RRs as described in 1. Perform connection establishment using HTTPS RRs as described in
Section 3, but do not fall back to the origin's A/AAAA records. Section 3, but do not fall back to address records (steps 5 and
If all the HTTPS RRs have an "echconfig" key, and they all fail, 6). If there are compatible HTTPS RRs, they all have an
"echconfig" key, and attempts to connect to them all fail,
terminate connection establishment. terminate connection establishment.
2. If the client implements Alt-Svc, try to connect using any 2. If the client implements Alt-Svc, try to connect using any
entries from the Alt-Svc cache. entries from the Alt-Svc cache.
3. Fall back to the origin's A/AAAA records if necessary. 3. Fall back to address records (steps 5 and 6 of Section 3) if
necessary.
As a latency optimization, clients MAY prefetch DNS records for later As a latency optimization, clients MAY prefetch DNS records for later
steps before they are needed. steps before they are needed.
8.2. Deployment considerations 8.2. Deployment considerations
An HTTPS RRSet containing some RRs with "echconfig" and some without An HTTPS RRSet containing some RRs with "echconfig" and some without
is vulnerable to a downgrade attack. This configuration is NOT is vulnerable to a downgrade attack. This configuration is NOT
RECOMMENDED. Zone owners who do use such a mixed configuration RECOMMENDED. Zone owners who do use such a mixed configuration
SHOULD mark the RRs with "echconfig" as more preferred (i.e. smaller SHOULD mark the RRs with "echconfig" as more preferred (i.e. smaller
SvcFieldPriority) than those without, in order to maximize the SvcPriority) than those without, in order to maximize the likelihood
likelihood that ECH will be used in the absence of an active that ECH will be used in the absence of an active adversary.
adversary.
9. Examples 9. Examples
9.1. Protocol enhancements 9.1. Protocol enhancements
Consider a simple zone of the form Consider a simple zone of the form:
simple.example. 300 IN A 192.0.2.1 simple.example. 300 IN A 192.0.2.1
AAAA 2001:db8::1 AAAA 2001:db8::1
The domain owner could add this record The domain owner could add this record:
simple.example. 7200 IN HTTPS 1 . alpn=h3 ... simple.example. 7200 IN HTTPS 1 . alpn=h3 ...
to indicate that simple.example uses HTTPS, and supports QUIC in to indicate that simple.example uses HTTPS, and supports QUIC in
addition to HTTPS over TCP (an implicit default). The record could addition to HTTPS over TCP (an implicit default). The record could
also include other information (e.g. non-standard port, ECH also include other information (e.g. non-standard port, ECH
configuration). configuration).
9.2. Apex aliasing 9.2. Apex aliasing
skipping to change at page 27, line 28 skipping to change at page 29, line 10
This configuration is entirely compatible with the "Apex aliasing" This configuration is entirely compatible with the "Apex aliasing"
example, whether the client supports HTTPS RRs or not. If the client example, whether the client supports HTTPS RRs or not. If the client
does support HTTPS RRs, all connections will be upgraded to HTTPS, does support HTTPS RRs, all connections will be upgraded to HTTPS,
and clients will use HTTP/3 if they can. Parameters are "bound" to and clients will use HTTP/3 if they can. Parameters are "bound" to
each server pool, so each server pool can have its own protocol, ECH each server pool, so each server pool can have its own protocol, ECH
configuration, etc. configuration, etc.
9.4. Non-HTTPS uses 9.4. Non-HTTPS uses
For services other than HTTPS, the SVCB RR and an [Attrleaf] label For services other than HTTPS, the SVCB RR and an Attrleaf label
will be used. For example, to reach an example resource of [Attrleaf] will be used. For example, to reach an example resource
"baz://api.example.com:8765", the following Alias Form SVCB record of "baz://api.example.com:8765", the following SVCB record would be
would be used to delegate to "svc4-baz.example.net." which in-turn used to alias it to "svc4-baz.example.net." which in-turn could
could return AAAA/A records and/or SVCB records in ServiceForm. return AAAA/A records and/or SVCB records in ServiceMode:
_8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net. _8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net.
HTTPS RRs use similar [Attrleaf] labels if the origin contains a non- HTTPS RRs use similar Attrleaf labels if the origin contains a non-
default port. default port.
10. Interaction with other standards 10. Interaction with other standards
This standard is intended to reduce connection latency and improve This standard is intended to reduce connection latency and improve
user privacy. Server operators implementing this standard SHOULD user privacy. Server operators implementing this standard SHOULD
also implement TLS 1.3 [RFC8446] and OCSP Stapling [RFC6066], both of also implement TLS 1.3 [RFC8446] and OCSP Stapling [RFC6066], both of
which confer substantial performance and privacy benefits when used which confer substantial performance and privacy benefits when used
in combination with SVCB records. in combination with SVCB records.
To realize the greatest privacy benefits, this proposal is intended To realize the greatest privacy benefits, this proposal is intended
for use over a privacy-preserving DNS transport (like DNS over TLS for use over a privacy-preserving DNS transport (like DNS over TLS
[RFC7858] or DNS over HTTPS [RFC8484]). However, performance [DoT] or DNS over HTTPS [DoH]). However, performance improvements,
improvements, and some modest privacy improvements, are possible and some modest privacy improvements, are possible without the use of
without the use of those standards. those standards.
Any specification for use of SVCB with a protocol MUST have an entry Any specification for use of SVCB with a protocol MUST have an entry
for its scheme under the SVCB RR type in the IANA DNS Underscore for its scheme under the SVCB RR type in the IANA DNS Underscore
Global Scoped Entry Registry [Attrleaf]. The scheme SHOULD have an Global Scoped Entry Registry [Attrleaf]. The scheme SHOULD have an
entry in the IANA URI Schemes Registry [RFC7595]. The scheme SHOULD entry in the IANA URI Schemes Registry [RFC7595]. The scheme SHOULD
have a defined specification for use with SVCB. have a defined specification for use with SVCB.
11. Security Considerations 11. Security Considerations
SVCB/HTTPS RRs are intended for distribution over untrusted channels, SVCB/HTTPS RRs are intended for distribution over untrusted channels,
and clients are REQUIRED to verify that the alternative service is and clients are REQUIRED to verify that the alternative endpoint is
authoritative for the origin (similar to Section 2.1 of [AltSvc]). authoritative for the service (similar to Section 2.1 of [AltSvc]).
Therefore, DNSSEC signing and validation are OPTIONAL for publishing Therefore, DNSSEC signing and validation are OPTIONAL for publishing
and using SVCB and HTTPS RRs. and using SVCB and HTTPS RRs.
Clients MUST ensure that their DNS cache is partitioned for each Clients MUST ensure that their DNS cache is partitioned for each
local network, or flushed on network changes, to prevent a local local network, or flushed on network changes, to prevent a local
adversary in one network from implanting a forged DNS record that adversary in one network from implanting a forged DNS record that
allows them to track users or hinder their connections after they allows them to track users or hinder their connections after they
leave that network. leave that network.
An attacker who can prevent SVCB resolution can deny clients any
associated security benefits. A hostile recursive resolver can
always deny service to SVCB queries, but network intermediaries can
often prevent resolution as well, even when the client and recursive
resolver validate DNSSEC and use a secure transport. These downgrade
attacks can prevent the HTTPS upgrade provided by the HTTPS RR
(Section 7.5), and disable the encryption enabled by the echconfig
SvcParamKey (Section 8). To prevent downgrades, Section 3.1
recommends that clients abandon the connection attempt when such an
attack is detected.
A hostile DNS intermediary might forge AliasForm "." records
(Section 2.5.1) as a way to block clients from accessing particular
services. Such an adversary could already block entire domains by
forging erroneous responses, but this mechanism allows them to target
particular protocols or ports within a domain. Clients that might be
subject to such attacks SHOULD ignore AliasForm "." records.
12. IANA Considerations 12. IANA Considerations
12.1. New registry for Service Parameters 12.1. SVCB RRType
This document defines a new DNS RR type, SVCB, whose value 64 has
been allocated by IANA from the "Resource Record (RR) TYPEs"
subregistry of the "Domain Name System (DNS) Parameters" registry:
Type: SVCB
Value: 64
Meaning: General Purpose Service Endpoints
Reference: This document
12.2. HTTPS RRType
This document defines a new DNS RR type, HTTPS, whose value 65 has
been allocated by IANA from the "Resource Record (RR) TYPEs"
subregistry of the "Domain Name System (DNS) Parameters" registry:
Type: HTTPS
Value: 65
Meaning: HTTPS Specific Service Endpoints
Reference: This document
12.3. New registry for Service Parameters
The "Service Binding (SVCB) Parameter Registry" defines the namespace The "Service Binding (SVCB) Parameter Registry" defines the namespace
for parameters, including string representations and numeric for parameters, including string representations and numeric
SvcParamKey values. This registry is shared with other SVCB- SvcParamKey values. This registry is shared with other SVCB-
compatible RR types, such as the HTTPS RR. compatible RR types, such as the HTTPS RR.
ACTION: create and include a reference to this registry. ACTION: create and include a reference to this registry.
12.1.1. Procedure 12.3.1. Procedure
A registration MUST include the following fields: A registration MUST include the following fields:
o Name: Service parameter key name o Number: SvcParamKey wire format numeric identifier (range 0-65535)
o SvcParamKey: Service parameter key numeric identifier (range o Name: SvcParamKey presentation name
0-65535)
o Meaning: a short description o Meaning: a short description
o Pointer to specification text o Pointer to specification text
SvcParamKey values to be added to this namespace have different SvcParamKey entries to be added to this namespace have different
policies ([RFC5226], Section 4.1) based on their range: policies ([RFC5226], Section 4.1) based on their range:
+-------------+-------------------------+ +-------------+-------------------------+
| SvcParamKey | IANA Policy | | Number | IANA Policy |
+-------------+-------------------------+ +-------------+-------------------------+
| 0-255 | Standards Action | | 0-255 | Standards Action |
| | | | | |
| 256-32767 | Expert Review | | 256-32767 | Expert Review |
| | | | | |
| 32768-65280 | First Come First Served | | 32768-65280 | First Come First Served |
| | | | | |
| 65280-65534 | Private Use | | 65280-65534 | Private Use |
| | | | | |
| 65535 | Standards Action | | 65535 | Standards Action |
+-------------+-------------------------+ +-------------+-------------------------+
Apart from the initial contents, the SvcParamKey name MUST NOT start Apart from the initial contents, the SvcParamKey name MUST NOT start
with "key". with "key".
12.1.2. Initial contents 12.3.2. Initial contents
The "Service Binding (SVCB) Parameter Registry" shall initially be The "Service Binding (SVCB) Parameter Registry" shall initially be
populated with the registrations below: populated with the registrations below:
+-------------+-----------------+----------------------+------------+ +-------------+-----------------+----------------------+------------+
| SvcParamKey | NAME | Meaning | Reference | | Number | Name | Meaning | Reference |
+-------------+-----------------+----------------------+------------+ +-------------+-----------------+----------------------+------------+
| 0 | (no name) | Reserved for | (This | | 0 | mandatory | Mandatory keys in | (This |
| | | internal use | document) | | | | this RR | document) |
| | | | | | | | | |
| 1 | alpn | Additional supported | (This | | 1 | alpn | Additional supported | (This |
| | | protocols | document) | | | | protocols | document) |
| | | | | | | | | |
| 2 | no-default-alpn | No support for | (This | | 2 | no-default-alpn | No support for | (This |
| | | default protocol | document) | | | | default protocol | document) |
| | | | | | | | | |
| 3 | port | Port for alternative | (This | | 3 | port | Port for alternative | (This |
| | | service | document) | | | | endpoint | document) |
| | | | | | | | | |
| 4 | ipv4hint | IPv4 address hints | (This | | 4 | ipv4hint | IPv4 address hints | (This |
| | | | document) | | | | | document) |
| | | | | | | | | |
| 5 | echconfig | Encrypted | (This | | 5 | echconfig | Encrypted | (This |
| | | ClientHello info | document) | | | | ClientHello info | document) |
| | | | | | | | | |
| 6 | ipv6hint | IPv6 address hints | (This | | 6 | ipv6hint | IPv6 address hints | (This |
| | | | document) | | | | | document) |
| | | | | | | | | |
| 65280-65534 | keyNNNNN | Private Use | (This | | 65280-65534 | keyNNNNN | Private Use | (This |
| | | | document) | | | | | document) |
| | | | | | | | | |
| 65535 | key65535 | Reserved | (This | | 65535 | key65535 | Reserved ("Invalid | (This |
| | | | document) | | | | key") | document) |
+-------------+-----------------+----------------------+------------+ +-------------+-----------------+----------------------+------------+
TODO: do we also want to reserve a range for greasing? TODO: do we also want to reserve a range for greasing?
12.2. Registry updates 12.4. Registry updates
Per [RFC6895], please add the following entries to the data type Per [RFC6895], please add the following entries to the data type
range of the Resource Record (RR) TYPEs registry: range of the Resource Record (RR) TYPEs registry:
+-------+------------------------------------------+----------------+ +-------+------------------------------------------+----------------+
| TYPE | Meaning | Reference | | TYPE | Meaning | Reference |
+-------+------------------------------------------+----------------+ +-------+------------------------------------------+----------------+
| SVCB | Service Location and Parameter Binding | (This | | SVCB | Service Location and Parameter Binding | (This |
| | | document) | | | | document) |
| | | | | | | |
skipping to change at page 31, line 17 skipping to change at page 33, line 17
+---------+------------+-----------------+-----------------+ +---------+------------+-----------------+-----------------+
| RR TYPE | _NODE NAME | Meaning | Reference | | RR TYPE | _NODE NAME | Meaning | Reference |
+---------+------------+-----------------+-----------------+ +---------+------------+-----------------+-----------------+
| HTTPS | _https | HTTPS SVCB info | (This document) | | HTTPS | _https | HTTPS SVCB info | (This document) |
+---------+------------+-----------------+-----------------+ +---------+------------+-----------------+-----------------+
13. Acknowledgments and Related Proposals 13. Acknowledgments and Related Proposals
There have been a wide range of proposed solutions over the years to There have been a wide range of proposed solutions over the years to
the "CNAME at the Zone Apex" challenge proposed. These include the "CNAME at the Zone Apex" challenge proposed. These include
[I-D.draft-bellis-dnsop-http-record-00], [I-D.bellis-dnsop-http-record], [I-D.ietf-dnsop-aname], and others.
[I-D.draft-ietf-dnsop-aname-03], and others.
Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thomson, Lucas Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thomson, Lucas
Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, David Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, David
Benjamin, and others for their feedback and suggestions on this Benjamin, and others for their feedback and suggestions on this
draft. draft.
14. References 14. References
14.1. Normative References 14.1. Normative References
[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[Attrleaf] [Attrleaf]
Crocker, D., "DNS Scoped Data Through "Underscore" Naming Crocker, D., "Scoped Interpretation of DNS Resource
of Attribute Leaves", draft-ietf-dnsop-attrleaf-16 (work Records through "Underscored" Naming of Attribute Leaves",
in progress), November 2018. BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
<https://www.rfc-editor.org/info/rfc8552>.
[base64] Josefsson, S., "The Base16, Base32, and Base64 Data [base64] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[DNAME] Rose, S. and W. Wijngaards, "DNAME Redirection in the [DNAME] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>. <https://www.rfc-editor.org/info/rfc6672>.
[DoH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[DoT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[ECH] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS [ECH] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS
Encrypted Client Hello", draft-ietf-tls-esni-07 (work in Encrypted Client Hello", draft-ietf-tls-esni-07 (work in
progress), June 2020. progress), June 2020.
[HappyEyeballsV2] [HappyEyeballsV2]
Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict [HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, Transport Security (HSTS)", RFC 6797,
DOI 10.17487/RFC6797, November 2012, DOI 10.17487/RFC6797, November 2012,
<https://www.rfc-editor.org/info/rfc6797>. <https://www.rfc-editor.org/info/rfc6797>.
[HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", draft-ietf-quic-http-20 (work in progress), (HTTP/3)", draft-ietf-quic-http-29 (work in progress),
April 2019. June 2020.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 1928, L. Jones, "SOCKS Protocol Version 5", RFC 1928,
DOI 10.17487/RFC1928, March 1996, DOI 10.17487/RFC1928, March 1996,
<https://www.rfc-editor.org/info/rfc1928>. <https://www.rfc-editor.org/info/rfc1928>.
skipping to change at page 33, line 21 skipping to change at page 35, line 31
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011, DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>. <https://www.rfc-editor.org/info/rfc6147>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/info/rfc6454>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013, RFC 7050, DOI 10.17487/RFC7050, November 2013,
<https://www.rfc-editor.org/info/rfc7050>. <https://www.rfc-editor.org/info/rfc7050>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35, and Registration Procedures for URI Schemes", BCP 35,
RFC 7595, DOI 10.17487/RFC7595, June 2015, RFC 7595, DOI 10.17487/RFC7595, June 2015,
<https://www.rfc-editor.org/info/rfc7595>. <https://www.rfc-editor.org/info/rfc7595>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[WebSocket] [WebSocket]
Fette, I. and A. Melnikov, "The WebSocket Protocol", Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, DOI 10.17487/RFC6455, December 2011, RFC 6455, DOI 10.17487/RFC6455, December 2011,
<https://www.rfc-editor.org/info/rfc6455>. <https://www.rfc-editor.org/info/rfc6455>.
14.2. Informative References 14.2. Informative References
[AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP [AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>. April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[DNSTerm] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [DNSTerm] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[FETCH] "Fetch Living Standard", May 2020, [FETCH] "Fetch Living Standard", May 2020,
<https://fetch.spec.whatwg.org/>. <https://fetch.spec.whatwg.org/>.
[I-D.draft-bellis-dnsop-http-record-00] [I-D.bellis-dnsop-http-record]
Bellis, R., "A DNS Resource Record for HTTP", draft- Bellis, R., "A DNS Resource Record for HTTP", draft-
bellis-dnsop-http-record-00 (work in progress), November bellis-dnsop-http-record-00 (work in progress), November
2018. 2018.
[I-D.draft-ietf-dnsop-aname-03] [I-D.ietf-dnsop-aname]
Finch, T., Hunt, E., Dijk, P., Eden, A., and W. Mekking, Finch, T., Hunt, E., Dijk, P., Eden, A., and W. Mekking,
"Address-specific DNS aliases (ANAME)", draft-ietf-dnsop- "Address-specific DNS aliases (ANAME)", draft-ietf-dnsop-
aname-03 (work in progress), April 2019. aname-04 (work in progress), July 2019.
[I-D.draft-tapril-ns2-00] [I-D.tapril-ns2]
April, T., "Parameterized Nameserver Delegation with NS2 April, T., "Parameterized Nameserver Delegation with NS2
and NS2T", draft-tapril-ns2-00 (work in progress), March and NS2T", draft-tapril-ns2-00 (work in progress), March
2020. 2020.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC6454, December 2011,
DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc6454>.
<https://www.rfc-editor.org/info/rfc2782>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>. April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
14.3. URIs 14.3. URIs
[1] https://github.com/MikeBishop/dns-alt-svc [1] https://github.com/MikeBishop/dns-alt-svc
Appendix A. Comparison with alternatives Appendix A. Decoding text in zone files
DNS zone files are capable of representing arbitrary octet sequences
in basic ASCII text, using various delimiters and encodings. The
algorithm for decoding these character-strings is defined in
Section 5.1 of [RFC1035]. Here we summarize the allowed input to
that algorithm, using ABNF:
; non-special is VCHAR minus DQUOTE, ";", "(", ")", and "\".
non-special = %x21 / %x23-27 / %x2A-3A / %x3C-5B / %x5D-7E
; non-digit is VCHAR minus DIGIT
non-digit = %x21-2F / %x3A-7E
; dec-octet is a number 0-255 as a three-digit decimal number.
dec-octet = ( "0" / "1" ) 2DIGIT /
"2" ( ( %x30-34 DIGIT ) / ( "5" %x30-35 ) )
escaped = "\" ( non-digit / dec-octet )
contiguous = 1*( non-special / escaped )
quoted = DQUOTE *( contiguous / ( ["\"] WSP ) ) DQUOTE
char-string = contiguous / quoted
The decoding algorithm allows "char-string" to represent any
"*OCTET". In this document, this algorithm is referred to as
"character-string decoding". The algorithm is the same as used by
"<character-string>" in RFC 1035, although the output length in this
document is not limited to 255 octets.
A.1. Decoding a value list
In order to represent lists of values in zone files, this
specification uses an extended version of character-string decoding
that adds the use of "," as a delimiter after double-quote
processing. When "," is not escaped (by a preceding "\" or as the
escape sequence "\044"), it separates values in the output, which is
a list of 1*OCTET. (For simplicity, empty values are not allowed.)
We refer to this modified procedure as "value-list decoding".
value-list = char-string
list-value = 1*OCTET
For example, consider these "char-string" SvcParamValues:
"part1,part2\,part3"
part1,part2\044part3
Character-string decoding either of these inputs would produce a
single "*OCTET" output:
part1,part2,part3
Value-list decoding either of these inputs would instead convert it
to a list of two "list-value"s:
part1
part2,part3
Appendix B. Comparison with alternatives
The SVCB and HTTPS RR types closely resemble, and are inspired by, The SVCB and HTTPS RR types closely resemble, and are inspired by,
some existing record types and proposals. A complaint with all of some existing record types and proposals. A complaint with all of
the alternatives is that web clients have seemed unenthusiastic about the alternatives is that web clients have seemed unenthusiastic about
implementing them. The hope here is that by providing an extensible implementing them. The hope here is that by providing an extensible
solution that solves multiple problems we will overcome the inertia solution that solves multiple problems we will overcome the inertia
and have a path to achieve client implementation. and have a path to achieve client implementation.
A.1. Differences from the SRV RR type B.1. Differences from the SRV RR type
An SRV record [RFC2782] can perform a similar function to the SVCB An SRV record [SRV] can perform a similar function to the SVCB
record, informing a client to look in a different location for a record, informing a client to look in a different location for a
service. However, there are several differences: service. However, there are several differences:
o SRV records are typically mandatory, whereas clients will always o SRV records are typically mandatory, whereas clients will always
continue to function correctly without making use of SVCB. continue to function correctly without making use of SVCB.
o SRV records cannot instruct the client to switch or upgrade o SRV records cannot instruct the client to switch or upgrade
protocols, whereas SVCB can signal such an upgrade (e.g. to protocols, whereas SVCB can signal such an upgrade (e.g. to
HTTP/2). HTTP/2).
o SRV records are not extensible, whereas SVCB and HTTPS RRs can be o SRV records are not extensible, whereas SVCB and HTTPS RRs can be
extended with new parameters. extended with new parameters.
A.2. Differences from the proposed HTTP record o SVCB records use 16 bit for SvcPriority for consistency with SRV
and other RR types that also use 16 bit priorities.
Unlike [I-D.draft-bellis-dnsop-http-record-00], this approach is B.2. Differences from the proposed HTTP record
extensible to cover Alt-Svc and Encrypted ClientHello use-cases.
Like that proposal, this addresses the zone apex CNAME challenge. Unlike [I-D.bellis-dnsop-http-record], this approach is extensible to
cover Alt-Svc and Encrypted ClientHello use-cases. Like that
proposal, this addresses the zone apex CNAME challenge.
Like that proposal, it remains necessary to continue to include Like that proposal, it remains necessary to continue to include
address records at the zone apex for legacy clients. address records at the zone apex for legacy clients.
A.3. Differences from the proposed ANAME record B.3. Differences from the proposed ANAME record
Unlike [I-D.draft-ietf-dnsop-aname-03], this approach is extensible Unlike [I-D.ietf-dnsop-aname], this approach is extensible to cover
to cover Alt-Svc and ECH use-cases. This approach also does not Alt-Svc and ECH use-cases. This approach also does not require any
require any changes or special handling on either authoritative or changes or special handling on either authoritative or primary
master servers, beyond optionally returning in-bailiwick additional servers, beyond optionally returning in-bailiwick additional records.
records.
Like that proposal, this addresses the zone apex CNAME challenge for Like that proposal, this addresses the zone apex CNAME challenge for
clients that implement this. clients that implement this.
However, with this SVCB proposal, it remains necessary to continue to However, with this SVCB proposal, it remains necessary to continue to
include address records at the zone apex for legacy clients. If include address records at the zone apex for legacy clients. If
deployment of this standard is successful, the number of legacy deployment of this standard is successful, the number of legacy
clients will fall over time. As the number of legacy clients clients will fall over time. As the number of legacy clients
declines, the operational effort required to serve these users declines, the operational effort required to serve these users
without the benefit of SVCB indirection should fall. Server without the benefit of SVCB indirection should fall. Server
operators can easily observe how much traffic reaches this legacy operators can easily observe how much traffic reaches this legacy
endpoint, and may remove the apex's address records if the observed endpoint, and may remove the apex's address records if the observed
legacy traffic has fallen to negligible levels. legacy traffic has fallen to negligible levels.
A.4. Comparison with separate RR types for AliasForm and ServiceForm B.4. Comparison with separate RR types for AliasMode and ServiceMode
Abstractly, functions of AliasForm and ServiceForm are independent, Abstractly, functions of AliasMode and ServiceMode are independent,
so it might be tempting to specify them as separate RR types. so it might be tempting to specify them as separate RR types.
However, this would result in a serious performance impairment, However, this would result in a serious performance impairment,
because clients cannot rely on their recursive resolver to follow because clients cannot rely on their recursive resolver to follow
SVCB aliases (unlike CNAME). Thus, clients would have to issue SVCB aliases (unlike CNAME). Thus, clients would have to issue
queries for both RR types in parallel, potentially at each step of queries for both RR types in parallel, potentially at each step of
the alias chain. Recursive resolvers that implement the the alias chain. Recursive resolvers that implement the
specification would, upon receipt of a ServiceForm query, emit both a specification would, upon receipt of a ServiceMode query, emit both a
ServiceForm and an AliasForm query to the authoritative. Thus, ServiceMode and an AliasMode query to the authoritative. Thus,
splitting the RR type would double, or in some cases triple, the load splitting the RR type would double, or in some cases triple, the load
on clients and servers, and would not reduce implementation on clients and servers, and would not reduce implementation
complexity. complexity.
Appendix B. Change history Appendix C. Change history
o draft-ietf-dnsop-svcb-https-01
* Added a "mandatory" SvcParamKey
* Added the ability to indicate that a service does not exist
* Adjusted resolution and ALPN algorithms
* Major terminology revisions for "origin" and CamelCase names
* Revised ABNF
* Include allocated RR type numbers
* Various corrections, explanations, and recommendations
o draft-ietf-dnsop-svcb-https-00 o draft-ietf-dnsop-svcb-https-00
* Rename HTTPSSVC RR to HTTPS RR * Rename HTTPSSVC RR to HTTPS RR
* Rename "an SVCB" to "a SVCB" * Rename "an SVCB" to "a SVCB"
* Removed "design considerations and open issues" section and * Removed "design considerations and open issues" section and
some other "to be removed" text some other "to be removed" text
 End of changes. 189 change blocks. 
541 lines changed or deleted 739 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/