draft-ietf-dnsop-svcb-httpssvc-00.txt   draft-ietf-dnsop-svcb-httpssvc-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: May 2, 2020 E. Nygren Expires: May 7, 2020 E. Nygren
Akamai Technologies Akamai Technologies
October 30, 2019 November 4, 2019
Service binding and parameter specification via the DNS (DNS SVCB and Service binding and parameter specification via the DNS (DNS SVCB and
HTTPSSVC) HTTPSSVC)
draft-ietf-dnsop-svcb-httpssvc-00 draft-ietf-dnsop-svcb-httpssvc-01
Abstract Abstract
This document specifies the "SVCB" and "HTTPSSVC" DNS resource record This document specifies the "SVCB" and "HTTPSSVC" DNS resource record
types to facilitate the lookup of information needed to make types to facilitate the lookup of information needed to make
connections for origin resources, such as for HTTPS URLs. SVCB connections for origin resources, such as for HTTPS URLs. SVCB
records allow an origin to be served from multiple network locations, records allow an origin to be served from multiple network locations,
each with associated parameters (such as transport protocol each with associated parameters (such as transport protocol
configuration and keying material for encrypting TLS SNI). They also configuration and keying material for encrypting TLS SNI). They also
enable aliasing of apex domains, which is not possible with CNAME. enable aliasing of apex domains, which is not possible with CNAME.
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 May 2, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 44 skipping to change at page 2, line 44
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Introductory Example . . . . . . . . . . . . . . . . . . 5 1.1. Introductory Example . . . . . . . . . . . . . . . . . . 5
1.2. Goals of the SVCB RR . . . . . . . . . . . . . . . . . . 6 1.2. Goals of the SVCB RR . . . . . . . . . . . . . . . . . . 6
1.3. Overview of the SVCB RR . . . . . . . . . . . . . . . . . 7 1.3. Overview of the SVCB RR . . . . . . . . . . . . . . . . . 7
1.4. Parameter for ESNI . . . . . . . . . . . . . . . . . . . 8 1.4. Parameter for ESNI . . . . . . . . . . . . . . . . . . . 8
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
2. The SVCB record type . . . . . . . . . . . . . . . . . . . . 8 2. The SVCB record type . . . . . . . . . . . . . . . . . . . . 8
2.1. Parameter specification via ServiceFieldValue . . . . . . 9 2.1. Parameter specification via ServiceFieldValue . . . . . . 9
2.1.1. Presentation format . . . . . . . . . . . . . . . . . 9 2.1.1. Presentation format . . . . . . . . . . . . . . . . . 9
2.2. SVCB RDATA Wire Format . . . . . . . . . . . . . . . . . 10 2.2. SVCB RDATA Wire Format . . . . . . . . . . . . . . . . . 10
2.3. SVCB owner names . . . . . . . . . . . . . . . . . . . . 11 2.3. SVCB owner names . . . . . . . . . . . . . . . . . . . . 10
2.4. SvcRecordType . . . . . . . . . . . . . . . . . . . . . . 11 2.4. SvcRecordType . . . . . . . . . . . . . . . . . . . . . . 11
2.5. SVCB records: AliasForm . . . . . . . . . . . . . . . . . 11 2.5. SVCB records: AliasForm . . . . . . . . . . . . . . . . . 11
2.6. SVCB records: ServiceForm . . . . . . . . . . . . . . . . 12 2.6. SVCB records: ServiceForm . . . . . . . . . . . . . . . . 12
2.6.1. Special handling of "." for SvcDomainName in 2.6.1. Special handling of "." for SvcDomainName in
ServiceForm . . . . . . . . . . . . . . . . . . . . . 13 ServiceForm . . . . . . . . . . . . . . . . . . . . . 12
2.6.2. SvcFieldPriority . . . . . . . . . . . . . . . . . . 13 2.6.2. SvcFieldPriority . . . . . . . . . . . . . . . . . . 13
3. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 13 3. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Clients using a Proxy . . . . . . . . . . . . . . . . . . 14 3.1. Clients using a Proxy . . . . . . . . . . . . . . . . . . 14
4. DNS Server Behavior . . . . . . . . . . . . . . . . . . . . . 15 4. DNS Server Behavior . . . . . . . . . . . . . . . . . . . . . 14
5. Performance optimizations . . . . . . . . . . . . . . . . . . 15 5. Performance optimizations . . . . . . . . . . . . . . . . . . 15
5.1. Optimistic pre-connection and connection reuse . . . . . 15 5.1. Optimistic pre-connection and connection reuse . . . . . 15
5.2. Preferring usable records . . . . . . . . . . . . . . . . 16 5.2. Preferring usable records . . . . . . . . . . . . . . . . 16
5.3. Structuring zones for performance . . . . . . . . . . . . 16 5.3. Structuring zones for performance . . . . . . . . . . . . 16
6. Initial SvcParamKeys . . . . . . . . . . . . . . . . . . . . 16 6. Initial SvcParamKeys . . . . . . . . . . . . . . . . . . . . 16
6.1. "alpn" . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. "alpn" . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. "port" . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. "port" . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. "esnikeys" . . . . . . . . . . . . . . . . . . . . . . . 17 6.3. "esniconfig" . . . . . . . . . . . . . . . . . . . . . . 17
6.4. "ipv4hint" and "ipv6hint" . . . . . . . . . . . . . . . . 17 6.4. "ipv4hint" and "ipv6hint" . . . . . . . . . . . . . . . . 17
7. Using SVCB with HTTPS and HTTP . . . . . . . . . . . . . . . 18 7. Using SVCB with HTTPS and HTTP . . . . . . . . . . . . . . . 18
7.1. Owner names for HTTPSSVC records . . . . . . . . . . . . 19 7.1. Owner names for HTTPSSVC records . . . . . . . . . . . . 19
7.2. Mapping between ServiceForm and Alt-Svc . . . . . . . . . 19 7.2. Populating Alt-Used . . . . . . . . . . . . . . . . . . . 19
7.3. Differences from Alt-Svc as transmitted over HTTP . . . . 21 7.3. Differences from Alt-Svc . . . . . . . . . . . . . . . . 19
7.3.1. Max Age and Persist . . . . . . . . . . . . . . . . . 21 7.3.1. Untrusted channel . . . . . . . . . . . . . . . . . . 19
7.4. Multiple records and preference ordering . . . . . . . . 21 7.3.2. Caching and granularity . . . . . . . . . . . . . . . 20
7.4.1. Constructing Alt-Svc equivalent headers . . . . . . . 21 7.4. HTTP Strict Transport Security . . . . . . . . . . . . . 20
7.5. Granularity and lifetime control . . . . . . . . . . . . 22 8. Alt-Svc and SVCB/HTTPSSVC parameter for ESNI keys . . . . . . 21
7.6. HTTP Strict Transport Security . . . . . . . . . . . . . 22 8.1. Handling a mixture of alternatives not supporting ESNI . 21
7.7. Cache interaction . . . . . . . . . . . . . . . . . . . . 23 9. Interaction with other standards . . . . . . . . . . . . . . 22
8. Extensions to enhance privacy . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. Alt-Svc and SVCB/HTTPSSVC parameter for ESNI keys . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.1.1. Handling a mixture of alternatives not supporting 11.1. New registry for Service Parameters . . . . . . . . . . 22
esnikeys . . . . . . . . . . . . . . . . . . . . . . 23 11.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . 23
9. Interaction with other standards . . . . . . . . . . . . . . 24 11.1.2. Initial contents . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 11.2. Registry updates . . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 12. Acknowledgments and Related Proposals . . . . . . . . . . . . 25
11.1. New registry for Service Parameters . . . . . . . . . . 25 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . 25 13.1. Normative References . . . . . . . . . . . . . . . . . . 25
11.1.2. Initial contents . . . . . . . . . . . . . . . . . . 25 13.2. Informative References . . . . . . . . . . . . . . . . . 28
11.2. Registry updates . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Mapping between HTTPSSVC and Alt-Svc . . . . . . . . 29
12. Acknowledgments and Related Proposals . . . . . . . . . . . . 27 A.1. Multiple records and preference ordering . . . . . . . . 30
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 A.2. Additional examples . . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . 27
13.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Additional examples . . . . . . . . . . . . . . . . 31
A.1. Equivalence to Alt-Svc records . . . . . . . . . . . . . 31
Appendix B. Comparison with alternatives . . . . . . . . . . . . 31 Appendix B. Comparison with alternatives . . . . . . . . . . . . 31
B.1. Differences from the SRV RR type . . . . . . . . . . . . 31 B.1. Differences from the SRV RR type . . . . . . . . . . . . 31
B.2. Differences from the proposed HTTP record . . . . . . . . 32 B.2. Differences from the proposed HTTP record . . . . . . . . 31
B.3. Differences from the proposed ANAME record . . . . . . . 32 B.3. Differences from the proposed ANAME record . . . . . . . 32
B.4. Differences from the proposed ESNI record . . . . . . . . 32 B.4. Differences from the proposed ESNI record . . . . . . . . 32
B.5. SNI Alt-Svc parameter . . . . . . . . . . . . . . . . . . 33 B.5. SNI Alt-Svc parameter . . . . . . . . . . . . . . . . . . 32
Appendix C. Design Considerations and Open Issues . . . . . . . 33 Appendix C. Design Considerations and Open Issues . . . . . . . 32
C.1. Record Name . . . . . . . . . . . . . . . . . . . . . . . 33 C.1. Record Name . . . . . . . . . . . . . . . . . . . . . . . 33
C.2. Generality . . . . . . . . . . . . . . . . . . . . . . . 33 C.2. Generality . . . . . . . . . . . . . . . . . . . . . . . 33
C.3. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 33 C.3. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 33
C.4. Where to include Priority . . . . . . . . . . . . . . . . 33 C.4. Where to include Priority . . . . . . . . . . . . . . . . 33
C.5. Whether to include Weight . . . . . . . . . . . . . . . . 33 C.5. Whether to include Weight . . . . . . . . . . . . . . . . 33
Appendix D. Change history . . . . . . . . . . . . . . . . . . . 34 Appendix D. Change history . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
The SVCB and HTTPSSVC RRs provide clients with complete instructions The SVCB and HTTPSSVC RRs provide clients with complete instructions
for access to an origin. This information enables improved for access to an origin. This information enables improved
performance and privacy by avoiding transient connections to a sub- performance and privacy by avoiding transient connections to a sub-
optimal default server, negotiating a preferred protocol, and optimal default server, negotiating a preferred protocol, and
providing relevant public keys. providing 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
skipping to change at page 5, line 29 skipping to change at page 5, line 26
1.1. Introductory Example 1.1. Introductory Example
As an introductory example for an HTTPS origin resource, a set of As an introductory example for an HTTPS origin resource, a set of
example HTTPSSVC and associated A+AAAA records might be: example HTTPSSVC and associated A+AAAA records might be:
www.example.com. 7200 IN CNAME svc.example.net. www.example.com. 7200 IN CNAME svc.example.net.
; AliasForm ; AliasForm
example.com. 7200 IN HTTPSSVC 0 svc.example.net. example.com. 7200 IN HTTPSSVC 0 svc.example.net.
; ServiceForm ; ServiceForm
svc.example.net. 7200 IN HTTPSSVC 2 svc3.example.net. ( alpn=h3 svc.example.net. 7200 IN HTTPSSVC 2 svc3.example.net. ( alpn=h3
port=8003 esnikeys="..." ) port=8003 esniconfig="..." )
svc.example.net. 7200 IN HTTPSSVC 3 svc2.example.net. ( alpn=h2 svc.example.net. 7200 IN HTTPSSVC 3 svc2.example.net. ( alpn=h2
port=8002 esnikeys="..." ) port=8002 esniconfig="..." )
svc2.example.net. 300 IN A 192.0.2.2 svc2.example.net. 300 IN A 192.0.2.2
svc2.example.net. 300 IN AAAA 2001:db8::2 svc2.example.net. 300 IN AAAA 2001:db8::2
svc3.example.net. 300 IN A 192.0.2.3 svc3.example.net. 300 IN A 192.0.2.3
svc3.example.net. 300 IN AAAA 2001:db8::3 svc3.example.net. 300 IN AAAA 2001:db8::3
; Compatibility records for non-HTTPSSVC-aware clients ; Compatibility records for non-HTTPSSVC-aware clients
example.com. 300 IN A 192.0.2.1 example.com. 300 IN A 192.0.2.1
example.com. 300 IN AAAA 2001:db8::1 example.com. 300 IN AAAA 2001:db8::1
svc.example.net. 300 IN A 192.0.2.1 svc.example.net. 300 IN A 192.0.2.1
svc.example.net. 300 IN AAAA 2001:db8::1 svc.example.net. 300 IN AAAA 2001:db8::1
skipping to change at page 7, line 7 skipping to change at page 6, line 50
o Support non-default TCP and UDP ports o Support non-default TCP and UDP ports
o Address a set of long-standing issues due to HTTP(S) clients not o Address a set of long-standing issues due to HTTP(S) clients not
implementing support for SRV records, as well as due to a implementing support for SRV records, as well as due to a
limitation that a DNS name can not have both CNAME and NS RRs (as limitation that a DNS name can not have both CNAME and NS RRs (as
is the case for zone apex names) is the case for zone apex names)
o Provide an HSTS-like indication signaling for the duration of the 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 DNS RR TTL that the HTTPS scheme should be used instead of HTTP
(see Section 7.6). (see Section 7.4).
1.3. Overview of the SVCB RR 1.3. 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 manner. (As mentioned above, this all applies equally to the
HTTPSSVC RR which shares the same encoding, format, and high-level HTTPSSVC RR which shares the same encoding, format, and high-level
semantics.) semantics.)
The SVCB RR has two forms: AliasForm and ServiceForm. SVCB RR The SVCB RR has two forms: AliasForm and ServiceForm. SVCB RR
entries with two non-empty fields are in AliasForm. When more fields entries with two non-empty fields are in AliasForm. When more fields
are present, this indicates that the SVCB RR is in ServiceForm. The are present, this indicates that the SVCB RR is in ServiceForm. The
fields are: fields are:
1. SvcFieldPriority: The priority of this record (relative to 1. SvcFieldPriority: The priority of this record (relative to
others, with lower values preferred). Applicable for the others, with lower values preferred). Applicable for the
ServiceForm, and otherwise has value "0". (Described in ServiceForm, and otherwise has value "0". (Described in
Section 7.4.) Appendix A.1.)
2. SvcDomainName: The domain name of either the alias target (for 2. SvcDomainName: The domain name of either the alias target (for
AliasForm) or the alternative service endpoint (for ServiceForm). AliasForm) or the alternative service endpoint (for ServiceForm).
3. SvcFieldValue: A list of key=value pairs describing the 3. SvcFieldValue: A list of key=value pairs describing the
alternative service endpoint for the domain name specified in alternative service endpoint for the domain name specified in
SvcDomainName (only for ServiceForm and otherwise empty). SvcDomainName (only for ServiceForm and otherwise empty).
Described in Section 2.1. Described in Section 2.1.
Cooperating DNS recursive resolvers will perform subsequent record Cooperating DNS recursive resolvers will perform subsequent record
skipping to change at page 7, line 48 skipping to change at page 7, line 44
recursive resolver or perform necessary SVCB, A, and AAAA record recursive resolver or perform necessary SVCB, A, and AAAA record
resolutions. DNS authoritative servers may attach in-bailiwick SVCB, resolutions. DNS authoritative servers may attach in-bailiwick SVCB,
A, AAAA, and CNAME records in the Additional Section to responses for A, AAAA, and CNAME records in the Additional Section to responses for
an SVCB query. an SVCB query.
When in the ServiceForm, the SvcFieldValue of the SVCB RR provides an When in the ServiceForm, the SvcFieldValue of the SVCB RR provides an
extensible data model for describing network endpoints that are extensible data model for describing network 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 endpoints.
For the HTTPS use-case with the HTTPSSVC RR, there is also direct For the HTTPS use-case, the HTTPSSVC RR enables many of the benefits
mapping from the SvcDomainName and SvcFieldValue into HTTP of [AltSvc], without waiting for a full HTTP connection initiation
Alternative Services (Alt-Svc) entries [AltSvc]. Encoding this (multiple roundtrips) before learning of the preferred alternative,
information here enables many of the benefits of Alt-Svc, without and without necessarily revealing the user's intended destination to
waiting for a full HTTP connection initiation (multiple roundtrips) all entities along the network path.
before learning of the preferred alternative, and without necessarily
revealing the user's intended destination to all entities along the
network path.
1.4. Parameter for ESNI 1.4. Parameter for ESNI
This document also defines a parameter for Encrypted SNI [ESNI] keys, This document also defines a parameter for Encrypted SNI [ESNI] keys,
both as a general SVCB parameter and also as a corresponding Alt-Svc both as a general SVCB parameter and also as a corresponding Alt-Svc
parameter. See Section 8.1. parameter. See Section 8.
1.5. Terminology 1.5. Terminology
For consistency with [AltSvc], we adopt the following definitions: For consistency with [AltSvc], we adopt the following definitions:
o An "origin" is an information source as in [RFC6454]. For o An "origin" is an information source as in [RFC6454]. For
services other than HTTPS, the exact definition will need to be services other than HTTPS, the exact definition will need to be
provided by the document mapping that service onto the SVCB RR. provided by the document mapping that service onto the SVCB RR.
o The "origin server" is the server that the client would reach when o The "origin server" is the server that the client would reach when
skipping to change at page 10, line 19 skipping to change at page 10, line 13
"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 of unrecognized keys leading zeros. In presentation format, values of unrecognized keys
should be represented in wire format, using decimal escape codes should be represented in wire format, using decimal escape codes
(e.g. \255) when necessary. (e.g. \255) when necessary.
2.2. SVCB RDATA Wire Format 2.2. SVCB 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 SvcFieldPriority as an integer in network byte
order. For AliasForm, SvcFieldPriority MUST be 0. order.
o the uncompressed SvcDomainName, represented as a sequence of o the uncompressed SvcDomainName, represented as a sequence of
length-prefixed labels as in Section 3.1 of [RFC1035]. length-prefixed labels as in Section 3.1 of [RFC1035].
o the SvcFieldValue byte string, consuming the remainder of the o the SvcFieldValue byte string, consuming the remainder of the
record (so smaller than 65535 octets and constrained by the RDATA record (so smaller than 65535 octets and constrained by the RDATA
and DNS message sizes). and DNS message sizes).
AliasForm is defined by SvcFieldValue being empty. AliasForm is defined by SvcFieldPriority being 0.
When SvcFieldValue is non-empty (ServiceForm), it contains a list of When SvcFieldValue is non-empty (ServiceForm), it contains a list of
SvcParamKey=SvcParamValue pairs with length-prefixes for the SvcParamKey=SvcParamValue pairs with length-prefixes for the
SvcParamValues, each of which contains: SvcParamValues, each of which contains:
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. network byte order.
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
skipping to change at page 11, line 29 skipping to change at page 11, line 22
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, clients MUST continue to validate
TLS certificate hostnames based on the origin host. TLS certificate hostnames based on the origin host.
As an example: As an example:
_8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net. _8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net.
svc4.example.net. 7200 IN SVCB 3 ( svc4.example.net. alpn="bar" svc4.example.net. 7200 IN SVCB 3 ( svc4.example.net. alpn="bar"
port="8004" esnikeys="..." ) port="8004" esniconfig="..." )
would indicate that "foo://api.example.com:8443" is aliased to use would indicate that "foo://api.example.com:8443" is aliased to use
ALPN protocol "bar" service endpoints offered at "svc4.example.net" ALPN protocol "bar" service endpoints offered at "svc4.example.net"
on port 8004. on port 8004.
2.4. SvcRecordType 2.4. SvcRecordType
The SvcRecordType is implicit based on the presence of SvcFieldValue, The SvcRecordType is indicated by the SvcFieldPriority, and defines
and defines the form of the SVCB RR. When SvcFieldValue is empty, the form of the SVCB RR. When SvcFieldPriority is 0, the SVCB
the SVCB SvcRecordType is defined to be in AliasForm. Otherwise, the SvcRecordType is defined to be in AliasForm. Otherwise, the SVCB
SVCB SvcRecordType is defined to be in ServiceForm. SvcRecordType is defined to be in ServiceForm.
Within an SVCB RRSet, all RRs should have the same SvcRecordType. If Within an SVCB RRSet, all RRs should have the same SvcRecordType. If
an RRSet contains a record in AliasForm, the client MUST ignore any an RRSet contains a record in AliasForm, the client MUST ignore any
records in the set with ServiceForm. records in the set with ServiceForm.
2.5. SVCB records: AliasForm 2.5. SVCB records: AliasForm
When SvcRecordType is AliasForm, the SVCB record is to be treated When SvcRecordType is AliasForm, the SVCB record is to be treated
similar to a CNAME alias pointing to SvcDomainName. SVCB RRSets similar to a CNAME alias pointing to SvcDomainName. SVCB RRSets
SHOULD only have a single resource record in this form. If multiple SHOULD only have a single resource record in this form. If multiple
skipping to change at page 12, line 44 skipping to change at page 12, line 37
For example, an AliasForm SVCB record does not alias to an HTTPSSVC For example, an AliasForm SVCB record does not alias to an HTTPSSVC
record, nor vice-versa. record, nor vice-versa.
2.6. SVCB records: ServiceForm 2.6. SVCB records: ServiceForm
When SvcRecordType is the ServiceForm, the combination of When SvcRecordType is the ServiceForm, the combination of
SvcDomainName and SvcFieldValue parameters within each resource SvcDomainName and SvcFieldValue parameters within each resource
record associates an alternative service location with its connection record associates an alternative service location with its connection
parameters. parameters.
Section 7.2 defines a direct mapping between Alt-Svc ([AltSvc]) Each protocol scheme that uses SVCB MUST define a protocol mapping
values and the SVCB ServiceForm. Protocols using SVCB may use this that explains how SvcFieldValues are applied for connections of that
Alt-Svc mapping or specify their own semantics. Unless specified scheme. Appendix A defines a limited mapping between Alt-Svc
([AltSvc]) values and the SVCB ServiceForm. Protocols using SVCB may
use this Alt-Svc mapping if they also use Alt-Svc. Unless specified
otherwise by the protocol mapping, clients MUST ignore SvcFieldValue otherwise by the protocol mapping, clients MUST ignore SvcFieldValue
parameters that they do not recognize. parameters that they do not recognize.
2.6.1. Special handling of "." for SvcDomainName in ServiceForm 2.6.1. Special handling of "." for SvcDomainName in ServiceForm
For ServiceForm SVCB RRs, if SvcDomainName has the value ".", then For ServiceForm SVCB RRs, if SvcDomainName has the value ".", then
the owner name of this record MUST be used as the effective the owner name of this record MUST be used as the effective
SvcDomainName. (The SvcDomainName of an SVCB RR in AliasForm MUST SvcDomainName. (The SvcDomainName of an SVCB RR in AliasForm MUST
NOT have this value.) NOT have this value.)
For example, in the following example "svc2.example.net" is the For example, in the following example "svc2.example.net" is the
effective SvcDomainName: effective SvcDomainName:
www.example.com. 7200 IN HTTPSSVC svc.example.net. www.example.com. 7200 IN HTTPSSVC svc.example.net.
svc.example.net. 7200 IN CNAME svc2.example.net. svc.example.net. 7200 IN CNAME svc2.example.net.
svc2.example.net. 7200 IN HTTPSSVC 0 . ( alpn=h2 svc2.example.net. 7200 IN HTTPSSVC 1 . ( alpn=h2
port=8002 esnikeys="..." ) port=8002 esniconfig="..." )
svc2.example.net. 300 IN A 192.0.2.2 svc2.example.net. 300 IN A 192.0.2.2
svc2.example.net. 300 IN AAAA 2001:db8::2 svc2.example.net. 300 IN AAAA 2001:db8::2
2.6.2. SvcFieldPriority 2.6.2. SvcFieldPriority
As RRs within an RRSet are explicitly unordered collections, the As RRs within an RRSet are explicitly unordered collections, the
SvcFieldPriority value serves to indicate priority. SVCB RRs with a SvcFieldPriority value serves to indicate priority. SVCB RRs with a
smaller SvcFieldPriority value SHOULD be given preference over RRs smaller SvcFieldPriority value SHOULD be given preference over RRs
with a larger SvcFieldPriority value. with a larger SvcFieldPriority value.
When receiving an RRSet containing multiple SVCB records with the When receiving an RRSet containing multiple SVCB records with the
same SvcFieldPriority value, clients SHOULD apply a random shuffle same SvcFieldPriority value, clients SHOULD apply a random shuffle
skipping to change at page 14, line 41 skipping to change at page 14, line 34
compatible with the client and the proxy. The client SHOULD provide compatible with the client and the proxy. The client SHOULD provide
the final SvcDomainName and port (if present) to the proxy as the the final SvcDomainName and port (if present) to the proxy as the
destination host and port. destination host and port.
Providing the proxy with the final SvcDomainName has several Providing the proxy with the final SvcDomainName has several
benefits: benefits:
o It allows the client to use the SvcFieldValue, if present, which o It allows the client to use the SvcFieldValue, if present, which
is only usable with a specific SvcDomainName. The SvcFieldValue is only usable with a specific SvcDomainName. The SvcFieldValue
may include information that enhances performance (e.g. alpn) and may include information that enhances performance (e.g. alpn) and
privacy (e.g. esnikeys). privacy (e.g. esniconfig).
o It allows the origin to delegate the apex domain. o It allows the origin 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
When replying to an SVCB query, authoritative DNS servers SHOULD When replying to an SVCB query, authoritative DNS servers SHOULD
skipping to change at page 15, line 20 skipping to change at page 15, line 8
SvcDomainNames. SvcDomainNames.
Recursive resolvers that are aware of SVCB SHOULD ensure that the Recursive resolvers that are aware of SVCB SHOULD ensure that the
client can execute the procedure in Section 3 without issuing a client can execute the procedure in Section 3 without issuing a
second round of queries, by following this procedure while second round of queries, by following this procedure while
constructing a response to a stub resolver for an SVCB record query: constructing a response to a stub resolver for an SVCB record query:
1. When processing an SVCB response from an authoritative server, 1. When processing an SVCB response from an authoritative server,
add it to the Additional section (unless it is the Answer). add it to the Additional section (unless it is the Answer).
2. Inspect whether each record is in AliasForm or ServiceForm. If 2. If all records are in ServiceForm, resolve A and AAAA records for
at least one record is in AliasForm, ignore all other SVCB
records in the RRSet.
3. If the record is in AliasForm, resolve A, AAAA, and SVCB records
for the SvcDomainName. If the SVCB record does not exist, add
the A and AAAA records to the Additional section. Otherwise, go
to step 1, subject to loop detection heuristics.
4. If the records are in ServiceForm, resolve A and AAAA records for
each SvcDomainName (or for the owner name if the SvcDomainName is each SvcDomainName (or for the owner name if the SvcDomainName is
"."), and include all the results in the Additional section. "."), and include all the results in the Additional section.
3. Otherwise, select an AliasForm record at random, and resolve A,
AAAA, and SVCB records for the SvcDomainName. If the SVCB record
does not exist, add the A and AAAA records to the Additional
section. Otherwise, go to step 1, subject to loop detection
heuristics.
All DNS servers SHOULD treat the SvcParam portion of the SVCB RR as All DNS servers SHOULD treat the SvcParam portion of the SVCB RR as
opaque and SHOULD NOT try to alter their behavior based on its 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
([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers
MUST accompany each RRSet in the Additional section with the same
DNSSEC-related records that it would send when providing that RRSet
as an Answer.
5. Performance optimizations 5. Performance optimizations
For optimal performance (i.e. minimum connection setup time), clients For optimal performance (i.e. minimum connection setup time), clients
SHOULD issue address (AAAA and/or A) and SVCB queries simultaneously, SHOULD issue address (AAAA and/or A) and SVCB queries simultaneously,
and SHOULD implement a client-side DNS cache. Responses in the and SHOULD implement a client-side DNS cache. Responses in the
Additional section of an SVCB response SHOULD be placed in cache Additional section of an SVCB response SHOULD be placed in cache
before performing any followup queries. With these optimizations in before performing any followup queries. With these optimizations in
place, and conforming DNS servers, using SVCB does not add network place, and conforming DNS servers, using SVCB does not add network
latency to connection setup. latency to connection setup.
5.1. Optimistic pre-connection and connection reuse 5.1. Optimistic pre-connection and connection reuse
If an address response arrives before the corresponding SVCB If an address response arrives before the corresponding SVCB
response, the client MAY initiate a connection as if the SVCB query response, the client MAY initiate a connection as if the SVCB query
returned NODATA, but MUST NOT transmit any information that could be returned NODATA, but MUST NOT transmit any information that could be
altered by the SVCB response until it arrives. For example, a TLS altered by the SVCB response until it arrives. For example, a TLS
ClientHello can be altered by the "esnikeys" value of an SVCB ClientHello can be altered by the "esniconfig" value of an SVCB
response (Section 6.3). Clients implementing this optimization response (Section 6.3). Clients implementing this optimization
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
an SVCB record is consistent with an active or in-progress connection an 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 ( esnikeys="111..." _1234._bar.example.com. 300 IN SVCB 1 svc1.example.net (
ipv6hint=2001:db8::1 port=1234 ... ) esniconfig="111..." ipv6hint=2001:db8::1 port=1234 ... )
SVCB 2 svc2.example.net ( esnikeys="222..." SVCB 2 svc2.example.net (
ipv6hint=2001:db8::2 port=1234 ... ) esniconfig="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 "esnikeys="222..."", even though the other record in the RRSet using "esniconfig="222..."", even though the other record in the
has higher priority. RRSet 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. Preferring usable records 5.2. Preferring usable records
A nonconforming recursive resolver might not return all the A nonconforming recursive resolver might not return all the
information required to use all the records in an SVCB response. If information required to use all the records in an SVCB response. 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
skipping to change at page 17, line 27 skipping to change at page 17, line 17
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. used to contact this alternative service.
The presentation format of the SvcParamValue is a numeric value The presentation format of the SvcParamValue is a numeric value
between 0 and 65535 inclusive. The wire format of the SvcParamValue between 0 and 65535 inclusive. The wire format of the SvcParamValue
is the corresponding 2 octet numeric value in network byte order. is the corresponding 2 octet numeric value in network byte order.
6.3. "esnikeys" 6.3. "esniconfig"
The SvcParamKey for ESNI is "esnikeys". Its value is defined in The SvcParamKey for ESNI is "esniconfig". Its value is defined in
Section 8.1. It is applicable to most TLS-based protocols. Section 8. It is applicable to most TLS-based protocols.
When publishing a record containing an "esnikeys" parameter, the When publishing a record containing an "esniconfig" parameter, the
publisher MUST ensure that all IP addresses of SvcDomainName publisher MUST ensure that all IP addresses of SvcDomainName
correspond to servers that have access to the corresponding private correspond to servers that have access to the corresponding private
key or are authoritative for the fallback domain. (See [ESNI] for key or are authoritative for the fallback domain. (See [ESNI] for
more details about the fallback domain.) This yields an anonymity more details about the fallback domain.) This yields an anonymity
set of cardinality equal to the number of ESNI-enabled server domains set of cardinality equal to the number of ESNI-enabled server domains
supported by a given client-facing server. Thus, even with SNI supported by a given client-facing server. Thus, even with SNI
encryption, an attacker who can enumerate the set of ESNI-enabled encryption, an attacker who can enumerate the set of ESNI-enabled
domains supported by a client-facing server can guess the correct SNI domains supported by a client-facing server can guess the correct SNI
with probability at least 1/K, where K is the size of this ESNI- with probability at least 1/K, where K is the size of this ESNI-
enabled server anonymity set. This probability may be increased via enabled server anonymity set. This probability may be increased via
skipping to change at page 18, line 43 skipping to change at page 18, line 34
are using compliant recursive resolvers. are using compliant recursive resolvers.
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
HTTPSSVC RR type is defined as an SVCB-compatible RR type, specific HTTPSSVC RR type is defined as an SVCB-compatible RR type, specific
to the https and http schemes. This handling includes a mapping from to the https and http schemes. Clients MUST NOT perform SVCB queries
HTTPSSVC records directly into Alt-Svc entries. Clients MUST NOT or accept SVCB responses for https or http schemes.
perform SVCB queries or accept SVCB responses for https or http
schemes.
The HTTPSSVC wire format and presentation format are identical to The HTTPSSVC 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 HTTPSSVC unless specified otherwise. equally to HTTPSSVC unless specified otherwise.
The presence of an HTTPSSVC record for an HTTP or HTTPS service also The presence of an HTTPSSVC record for an HTTP or HTTPS service also
provides an indication that all resources are available over HTTPS, provides an indication that all resources are available over HTTPS,
as discussed in Section 7.6. This allows HTTPSSVC RRs to apply to as discussed in Section 7.4. This allows HTTPSSVC RRs to apply to
pre-existing HTTP scheme URLs, while ensuring that the client uses a pre-existing HTTP scheme URLs, while ensuring that the client uses a
secure and authenticated HTTPS connection. secure and authenticated HTTPS connection.
The HTTPSSVC RR extends the concept introduced in the HTTP The HTTPSSVC RR parallels the concepts introduced in the HTTP
Alternative Services proposed standard [AltSvc]. Alt-Svc defines: Alternative Services proposed standard [AltSvc]. Clients and servers
that implement HTTPSSVC are NOT REQUIRED to implement Alt-Svc.
o an extensible data model for describing alternative network However, many clients and servers will implement both, and a partial
endpoints that are authoritative for an origin mapping exists between them (Appendix A).
o the "Alt-Svc Field Value", a text format for representing this
information
o standards for sending information in this format from a server to
a client over HTTP/1.1 and HTTP/2.
Each ServiceForm HTTPSSVC RR provides a set of information that can
be mapped into an Alt-Svc Field Value. A client receiving this
information during DNS resolution can skip the initial connection and
proceed directly to an alternative service.
7.1. Owner names for HTTPSSVC records 7.1. Owner names for HTTPSSVC records
The HTTPSSVC RR extends the behavior for determining a QNAME The HTTPSSVC RR extends the behavior for determining a QNAME
specified above in Section 2.3. In particular, if the scheme is specified above in Section 2.3. In particular, if the scheme is
"https" with port 443, or the scheme is "http" and the port is 80, "https" with port 443, or the scheme is "http" and the port is 80,
then the client's original QNAME is equal to the origin host name. then the client's original QNAME is equal to the origin host name.
For origins other than https with port 443 and http with port 80, the For origins other than https with port 443 and http with port 80, the
port and scheme continue to be prefixed to the hostname as described port and scheme continue to be prefixed to the hostname as described
in Section 2.3. Following of HTTPSSVC AliasForm and CNAME aliases is in Section 2.3. Following of HTTPSSVC AliasForm and CNAME aliases is
also unchanged from SVCB. also unchanged from SVCB.
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 host.
7.2. Mapping between ServiceForm and Alt-Svc 7.2. Populating Alt-Used
To construct an Alt-Svc Field Value (as defined in Section 4 of
[AltSvc]) from an HTTPSSVC record:
o The SvcDomainName is mapped into the uri-host portion of alt-
authority with the trailing "." removed. (If SvcDomainName is
".", the special handling described in Section 2.6.1 MUST be
applied first.)
o The SvcParamValue of the "port" service parameter, or 443 if no
such parameter is present, is written to the port portion of the
alt-authority.
o The SvcParamValue of the "alpn" service parameter is mapped to the
protocol-id. This MUST follow the normalization and encoding
requirements for protocol-id specified in [AltSvc] Section 3.
This parameter is MANDATORY.
o The DNS TTL is mapped to the "ma" (max age) Alt-Svc parameter.
o For SVCB parameters with defined mappings to HTTPS Alt-Svc, each
should be included as an Alt-Svc parameter, typically as the
SvcParamKey name "=" a defined encoding of the SvcParamValue.
Converting an Alt-Svc Field Value into an HTTPSSVC record follows the
reverse of this procedure.
Conversion from HTTPSSVC to Alt-Svc Field Value SHOULD ignore any
unrecognized SvcParamKeys, and conversion from Alt-Svc Field Value to
HTTPSSVC SHOULD ignore any Alt-Svc parameters that do not have a
corresponding SvcParamKey.
For example, if the operator of https://www.example.com intends to
include an HTTP response header like
Alt-Svc: h3="svc.example.net:8003"; ma=3600; foo=123, \
h2="svc.example.net:8002"; ma=3600; foo=123
they could also publish an HTTPSSVC DNS RRSet like When using an HTTPSSVC RR in ServiceForm, all clients SHOULD include
the "Alt-Used" HTTP header (Section 5 of [RFC7838]). The header's
value (in ABNF) SHOULD be
www.example.com. 3600 IN HTTPSSVC 2 svc.example.net. ( uri-host ":" port
alpn=h3 port=8003 foo=123 )
HTTPSSVC 3 svc.example.net. (
alpn=h2 port=8002 foo=123 )
Where "foo" is a hypothetical future HTTPSSVC and Alt-Svc parameter. where uri-host is the final value of HOST ({client-behavior}) minus
the trailing ".", and port is the port number in use.
This data type can also be represented as an Unknown RR as described 7.3. Differences from Alt-Svc
in [RFC3597]:
www.example.com. 3600 IN TYPE??? \\# TBD:WRITEME Publishing a ServiceForm HTTPSSVC record in DNS is intended to be
similar to transmitting the corresponding Alt-Svc field value over
HTTPS, and receiving an HTTPSSVC record is intended to be similar to
receiving that field value over HTTPS. However, there are some
differences in the intended client and server behavior.
On connections to an HTTPSSVC alternative service, clients SHOULD 7.3.1. Untrusted channel
include the same Alt-Used header that they would include if the
corresponding Alt-Svc Field Value were received over HTTPS.
7.3. Differences from Alt-Svc as transmitted over HTTP SVCB does not require or provide any assurance of authenticity.
(DNSSEC signing and verification, which would provide such assurance,
are OPTIONAL.) The DNS resolution process is treated as an untrusted
channel that learns only the QNAME, and is prevented from mounting
any attack beyond denial of service.
Publishing an alternative services form HTTPSSVC record in DNS is Alt-Svc parameters that cannot be safely received in this model MUST
intended to be equivalent to transmitting the corresponding Alt-Svc NOT have a corresponding defined SvcParamKey. For example, there is
value over HTTPS, and receiving an HTTPSSVC record is intended to be no SvcParamKey corresponding to the Alt-Svc "persist" parameter,
equivalent to receiving this field value over HTTPS. However, there because this parameter is not safe to accept over an untrusted
are some small differences in the intended client and server channel.
behavior.
7.3.1. Max Age and Persist 7.3.2. Caching and granularity
There is no SvcParamKey corresponding to the Alt-Svc "ma" (max age) There is no SvcParamKey corresponding to the Alt-Svc "ma" (max age)
parameter. Instead, server operators SHOULD encode the expiration parameter. Instead, server operators SHOULD encode the expiration
time in the DNS TTL, and MUST NOT set a TTL longer than the intended time in the DNS TTL.
"max age".
For security reasons, there is no SvcParamKey corresponding to the
Alt-Svc "persist" parameter.
7.4. Multiple records and preference ordering
Server operators MAY publish multiple ServiceForm HTTPSSVC records as
an RRSet. When converting a collection of alt-values into an
HTTPSSVC RRSet, the server operator MUST set the overall TTL to a
value no larger than the minimum of the "max age" values (following
Section 5.2 of [RFC2181]).
Each RR corresponds to exactly one alt-value, as described in
Section 3 of [AltSvc].
As discussed in Section 2.6.2, HTTPSSVC RRs with a smaller
SvcFieldPriority value SHOULD be sorted ahead of and given preference
over RRs with a larger SvcFieldPriority value.
Clients SHOULD prefer Alt-values received via HTTPS over any Alt-
value received via DNS.
7.4.1. Constructing Alt-Svc equivalent headers
1. The RRs SHOULD be ordered by increasing SvcFieldPriority, with
shuffling for equal SvcFieldPriority values. Clients MAY choose
to further prioritize alt-values where address records are
immediately available for the alt-value's SvcDomainName.
2. The client SHOULD concatenate the thus-transformed-and-ordered
SvcFieldValues in the RRSet, separated by commas. (This is
semantically equivalent to receiving multiple Alt-Svc HTTP
response headers, according to Section 3.2.2 of [HTTP]).
7.5. Granularity and lifetime control Some DNS caching systems incorrectly extend the lifetime of DNS
records beyond the stated TTL. Server operators MUST NOT rely on
HTTPSSVC records expiring on time, and MAY shorten the TTL to
compensate.
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 HTTPSSVC DNS Field Value specifically to the client. When using an HTTPSSVC DNS
record, groups of clients will necessarily receive the same Alt-Svc record, groups of clients will necessarily receive the same Alt-Svc
Field Value. Therefore, this standard is not suitable for uses that Field Value. Therefore, HTTPSSVC is not suitable for uses that
require single-client granularity in Alt-Svc. require single-client granularity.
Some DNS caching systems incorrectly extend the lifetime of DNS If the client has an Alt-Svc cache, and a usable Alt-Svc value is
records beyond the stated TTL. Server operators MUST NOT rely on present in that cache, then the client MAY skip the HTTPSSVC query.
HTTPSSVC records expiring on time, and MAY shorten the TTL to
compensate.
7.6. HTTP Strict Transport Security If the client has a cached Alt-Svc entry that is expiring, the client
MAY perform an HTTPSSVC query to refresh the entry.
7.4. HTTP Strict Transport Security
By publishing an HTTPSSVC record, the server operator indicates that By publishing an HTTPSSVC record, the server operator indicates that
all 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 HTTPSSVC similar to HTTP Strict Transport Security [HSTS]. When an HTTPSSVC
record is present for an origin, all "http" scheme requests for that record is present for an origin, all "http" scheme requests for that
origin SHOULD logically be redirected to "https". 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 an HTTPSSVC record is available for that lookup to determine if an HTTPSSVC record is available for that
origin. To do so, the client SHOULD construct a corresponding origin. To do so, the client SHOULD construct a corresponding
skipping to change at page 23, line 11 skipping to change at page 21, line 20
SHOULD abandon the connection attempt and display an error message. SHOULD abandon the connection attempt and display an error message.
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 an active attacker recursive resolver is DNSSEC-validating, and an active attacker
between the recursive resolver and the authoritative DNS server is between the recursive resolver and the authoritative DNS server is
attempting to prevent the upgrade to HTTPS. attempting to prevent the upgrade to HTTPS.
Similarly, if the client enforces DNSSEC validation on A/AAAA Similarly, if the client enforces DNSSEC validation on A/AAAA
responses, it SHOULD abandon the connection attempt if the HTTPSSVC responses, it SHOULD abandon the connection attempt if the HTTPSSVC
response fails to validate. response fails to validate.
7.7. Cache interaction 8. Alt-Svc and SVCB/HTTPSSVC parameter for ESNI keys
If the client has an Alt-Svc cache, and a usable Alt-Svc value is
present in that cache, then the client SHOULD NOT issue an HTTPSSVC
DNS query. Instead, the client SHOULD proceed with alternative
service connection as usual.
If the client has a cached Alt-Svc entry that is expiring, the client
MAY perform an HTTPSSVC query to refresh the entry.
8. Extensions to enhance privacy
8.1. Alt-Svc and SVCB/HTTPSSVC parameter for ESNI keys
Both SVCB/HTTPSSVC and Alt-Svc "esnikeys" parameters are defined for Both SVCB/HTTPSSVC and Alt-Svc "esniconfig" parameters are defined
specifying ESNI keys corresponding to an alternative service. The for conveying the ESNI configuration of an alternative service. The
value of the parameter is an ESNIKeys structure [ESNI] or the empty value of the parameter is an ESNIConfig structure [ESNI] or the empty
string. ESNI-aware clients SHOULD prefer alt-values and SVCB/ string. ESNI-aware clients SHOULD prefer alt-values and SVCB/
HTTPSSVC RRs with non-empty esnikeys. HTTPSSVC RRs with non-empty esniconfig.
Both the SVCB SvcParamValue presentation format as well as the Alt- Both the SVCB SvcParamValue presentation format as well as the Alt-
Svc parameter value is the ESNIKeys structure [ESNI] encoded in Svc parameter value is the ESNIConfig structure [ESNI] encoded in
[base64] or the empty string. The SVCB SvcParamValue wire format is [base64] or the empty string. The SVCB SvcParamValue wire format is
the octet string containing the binary ESNIKeys structure. the octet string containing the binary ESNIConfig structure.
This parameter MAY also be sent in Alt-Svc HTTP response headers and This parameter MAY also be sent in Alt-Svc HTTP response headers and
HTTP/2 ALTSVC frames. This parameter MUST NOT appear more than once HTTP/2 ALTSVC frames. This parameter MUST NOT appear more than once
in a single alt-value. in a single alt-value.
8.1.1. Handling a mixture of alternatives not supporting esnikeys 8.1. Handling a mixture of alternatives not supporting ESNI
The Alt-Svc specification states that "the client MAY fall back to The Alt-Svc specification states that "the client MAY fall back to
using the origin" in case of connection failure (Section 2.4 of using the origin" in case of connection failure (Section 2.4 of
[AltSvc]). This behavior is not suitable for ESNI, because fallback [AltSvc]). This behavior is not suitable for ESNI, because fallback
would negate the privacy benefits of ESNI. would negate the privacy benefits of ESNI.
Accordingly, any connection attempt that uses ESNI MUST fall back Accordingly, any connection attempt that uses ESNI MUST fall back
only to another alt-value that also has the esnikeys parameter. If only to another alt-value that also has the esniconfig parameter. If
the parameter's value is the empty string, the client SHOULD connect the parameter's value is the empty string, the client SHOULD connect
as it would in the absence of any ESNIKeys information. as it would in the absence of any ESNIConfig information.
For example, suppose a server operator has two alternatives. For example, suppose a server operator has two alternatives.
Alternative A is reliably accessible but does not support ESNI. Alternative A is reliably accessible but does not support ESNI.
Alternative B supports ESNI but is not reliably accessible. The Alternative B supports ESNI but is not reliably accessible. The
server operator could include a full esnikeys value in Alternative B, server operator could include a full esniconfig value in Alternative
and mark Alternative A with esnikeys="" to indicate that fallback B, and mark Alternative A with esniconfig="" to indicate that
from B to A is allowed. fallback from B to A is allowed.
Other clients and services implementing SVCB or HTTPSSVC with Other clients and services implementing SVCB or HTTPSSVC with
esnikeys are encouraged to take a similar approach. esniconfig are encouraged to take a similar approach.
9. Interaction with other standards 9. 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 [RFC7858] or DNS over HTTPS [RFC8484]). However, performance
improvements, and some modest privacy improvements, are possible improvements, and some modest privacy improvements, are possible
without the use of those standards. without the use of 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, unless it already has have a defined specification for use with SVCB.
a specification for use with Alt-Svc.
10. Security Considerations 10. Security Considerations
SVCB/HTTPSSVC RRs and Alt-Svc Field Values are intended for SVCB/HTTPSSVC RRs are intended for distribution over untrusted
distribution over untrusted channels, and clients are REQUIRED to channels, and clients are REQUIRED to verify that the alternative
verify that the alternative service is authoritative for the origin service is authoritative for the origin (Section 2.1 of [AltSvc]).
(Section 2.1 of [AltSvc]). Therefore, DNSSEC signing and validation Therefore, DNSSEC signing and validation are OPTIONAL for publishing
are OPTIONAL for publishing and using SVCB and HTTPSSVC records. and using SVCB and HTTPSSVC records.
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.
11. IANA Considerations 11. IANA Considerations
11.1. New registry for Service Parameters 11.1. New registry for Service Parameters
skipping to change at page 26, line 5 skipping to change at page 24, line 5
Values to be added to this name space require Expert Review (see Values to be added to this name space require Expert Review (see
[RFC5226], Section 4.1). Apart from the initial contents, the name [RFC5226], Section 4.1). Apart from the initial contents, the name
MUST NOT start with "key". MUST NOT start with "key".
11.1.2. Initial contents 11.1.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 | | SvcParamKey | NAME | Meaning | Reference |
+-------------+----------+--------------------------+---------------+ +-------------+------------+------------------------+---------------+
| 0 | key0 | Reserved | (This | | 0 | key0 | Reserved | (This |
| | | | document) | | | | | document) |
| | | | | | | | | |
| 1 | alpn | ALPN for alternative | (This | | 1 | alpn | ALPN for alternative | (This |
| | | service | document) | | | | service | document) |
| | | | | | | | | |
| 2 | port | Port for alternative | (This | | 2 | port | Port for alternative | (This |
| | | service | document) | | | | service | document) |
| | | | | | | | | |
| 3 | esnikeys | ESNI keys literal | (This | | 3 | esniconfig | Encrypted SNI | (This |
| | | | document) | | | | configuration | document) |
| | | | | | | | | |
| 4 | ipv4hint | IPv4 address hints | (This | | 4 | ipv4hint | IPv4 address hints | (This |
| | | | document) | | | | | document) |
| | | | | | | | | |
| 5 | key5 | Reserved | (This | | 5 | key5 | Reserved | (This |
| | | | document) | | | | | 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 | (This |
| | | | document) | | | | | document) |
+-------------+----------+--------------------------+---------------+ +-------------+------------+------------------------+---------------+
TODO: do we also want to reserve a range for greasing? TODO: do we also want to reserve a range for greasing?
11.2. Registry updates 11.2. Registry updates
Per [RFC6895], please add the following entry to the data type range Per [RFC6895], please add the following entry to the data type range
of the Resource Record (RR) TYPEs registry: of the Resource Record (RR) TYPEs registry:
+----------+----------------------------------------+---------------+ +----------+----------------------------------------+---------------+
| TYPE | Meaning | Reference | | TYPE | Meaning | Reference |
skipping to change at page 27, line 18 skipping to change at page 25, line 18
| RR TYPE | _NODE NAME | Meaning | Reference | | RR TYPE | _NODE NAME | Meaning | Reference |
+----------+------------+-------------------+-----------------+ +----------+------------+-------------------+-----------------+
| HTTPSSVC | _https | Alt-Svc for HTTPS | (This document) | | HTTPSSVC | _https | Alt-Svc for HTTPS | (This document) |
| | | | | | | | | |
| HTTPSSVC | _http | Alt-Svc for HTTPS | (This document) | | HTTPSSVC | _http | Alt-Svc for HTTPS | (This document) |
+----------+------------+-------------------+-----------------+ +----------+------------+-------------------+-----------------+
Per [AltSvc], please add the following entry to the HTTP Alt-Svc Per [AltSvc], please add the following entry to the HTTP Alt-Svc
Parameter Registry: Parameter Registry:
+-------------------+--------------------+-----------------+ +-------------------+-----------------------------+-----------------+
| Alt-Svc Parameter | Meaning | Reference | | Alt-Svc Parameter | Meaning | Reference |
+-------------------+--------------------+-----------------+ +-------------------+-----------------------------+-----------------+
| esnikeys | Encrypted SNI keys | (This document) | | esniconfig | Encrypted SNI configuration | (This document) |
+-------------------+--------------------+-----------------+ +-------------------+-----------------------------+-----------------+
12. Acknowledgments and Related Proposals 12. 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.draft-bellis-dnsop-http-record-00],
[I-D.draft-ietf-dnsop-aname-03], and others. [I-D.draft-ietf-dnsop-aname-03], and others.
Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thompson, Lucas Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thompson, Lucas
Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, and Pardue, Ilari Liusvaara, Tim Wicinski, Tommy Pauly, Chris Wood, and
skipping to change at page 28, line 46 skipping to change at page 26, line 46
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>. <https://www.rfc-editor.org/info/rfc2181>.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
RFC 3225, DOI 10.17487/RFC3225, December 2001,
<https://www.rfc-editor.org/info/rfc3225>.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
2003, <https://www.rfc-editor.org/info/rfc3597>. 2003, <https://www.rfc-editor.org/info/rfc3597>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
skipping to change at page 30, line 5 skipping to change at page 27, line 50
[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>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 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
skipping to change at page 31, line 5 skipping to change at page 29, line 5
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000, DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>. <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>.
Appendix A. Additional examples Appendix A. Mapping between HTTPSSVC and Alt-Svc
A.1. Equivalence to Alt-Svc records Conversion between HTTPSSVC's ServiceForm and Alt-Svc is possible.
Note that conversion in either direction can be lossy, because some
parameters are only defined for HTTPSSVC or Alt-Svc.
To construct an Alt-Svc Field Value (as defined in Section 4 of
[AltSvc]) from an HTTPSSVC record:
o The SvcDomainName is mapped into the uri-host portion of alt-
authority with the trailing "." removed. (If SvcDomainName is
".", the special handling described in Section 2.6.1 MUST be
applied first.)
o The SvcParamValue of the "port" service parameter, or 443 if no
such parameter is present, is written to the port portion of the
alt-authority.
o The SvcParamValue of the "alpn" service parameter is mapped to the
protocol-id. This MUST follow the normalization and encoding
requirements for protocol-id specified in [AltSvc] Section 3.
This parameter is MANDATORY.
o The DNS TTL is mapped to the "ma" (max age) Alt-Svc parameter.
o For SVCB parameters with defined mappings to HTTPS Alt-Svc, each
should be included as an Alt-Svc parameter, typically as the
SvcParamKey name "=" a defined encoding of the SvcParamValue.
Converting an Alt-Svc Field Value into an HTTPSSVC record follows the
reverse of this procedure.
Conversion between HTTPSSVC and Alt-Svc Field Value MUST ignore any
SvcParamKeys and Alt-Svc parameters that are unrecognized or do not
have a defined mapping.
For example, if the operator of https://www.example.com intends to
include an HTTP response header like
Alt-Svc: h3="svc.example.net:8003"; ma=3600; foo=123, \
h2="svc.example.net:8002"; ma=3600; foo=123
they could also publish an HTTPSSVC DNS RRSet like
www.example.com. 3600 IN HTTPSSVC 2 svc.example.net. (
alpn=h3 port=8003 foo=123 )
HTTPSSVC 3 svc.example.net. (
alpn=h2 port=8002 foo=123 )
Where "foo" is a hypothetical future HTTPSSVC and Alt-Svc parameter.
This data type can also be represented as an Unknown RR as described
in [RFC3597]:
www.example.com. 3600 IN TYPE??? \\# TBD:WRITEME
A.1. Multiple records and preference ordering
Server operators MAY publish multiple ServiceForm HTTPSSVC records as
an RRSet. When converting a collection of alt-values into an
HTTPSSVC RRSet, the server operator MUST set the overall TTL to a
value no larger than the minimum of the "max age" values (following
Section 5.2 of [RFC2181]).
Each RR corresponds to exactly one alt-value, as described in
Section 3 of [AltSvc].
As discussed in Section 2.6.2, HTTPSSVC RRs with a smaller
SvcFieldPriority value SHOULD be sorted ahead of and given preference
over RRs with a larger SvcFieldPriority value.
When constructing equivalent Alt-Svc headers from an RRSet:
1. The RRs SHOULD be ordered by increasing SvcFieldPriority, with
shuffling for equal SvcFieldPriority values. Clients MAY choose
to further prioritize alt-values where address records are
immediately available for the alt-value's SvcDomainName.
2. The client SHOULD concatenate the thus-transformed-and-ordered
SvcFieldValues in the RRSet, separated by commas. (This is
semantically equivalent to receiving multiple Alt-Svc HTTP
response headers, according to Section 3.2.2 of [HTTP]).
A.2. Additional examples
The following: The following:
www.example.com. 7200 IN CNAME svc.example.net. www.example.com. 7200 IN CNAME svc.example.net.
example.com. 7200 IN HTTPSSVC 0 svc.example.net. example.com. 7200 IN HTTPSSVC 0 svc.example.net.
svc.example.net. 7200 IN HTTPSSVC 2 svc3.example.net. ( svc.example.net. 7200 IN HTTPSSVC 2 svc3.example.net. (
alpn=h3 port=8003 esnikeys="ABC..." ) alpn=h3 port=8003 esniconfig="ABC..." )
svc.example.net. 7200 IN HTTPSSVC 3 . alpn=h2 port=8002 esnikeys="123..." svc.example.net. 7200 IN HTTPSSVC 3 . (
alpn=h2 port=8002 esniconfig="123..." )
is equivalent to the Alt-Svc record: is equivalent to the Alt-Svc record:
Alt-Svc: h3="svc3.example.net:8003"; esnikeys="ABC..."; ma=7200, \ Alt-Svc: h3="svc3.example.net:8003"; esniconfig="ABC..."; ma=7200, \
h2="svc.example.net:8002"; esnikeys="123..."; ma=7200 h2="svc.example.net:8002"; esniconfig="123..."; ma=7200
for the origins of both "https://www.example.com" and for the origins of both "https://www.example.com" and
"https://example.com". "https://example.com".
Appendix B. Comparison with alternatives Appendix B. Comparison with alternatives
The SVCB and HTTPSSVC record types closely resemble, and are inspired The SVCB and HTTPSSVC record types closely resemble, and are inspired
by, some existing record types and proposals. A complaint with all by, some existing record types and proposals. A complaint with all
of the alternatives is that web clients have seemed unenthusiastic of the alternatives is that web clients have seemed unenthusiastic
about implementing them. The hope here is that by providing an about implementing them. The hope here is that by providing an
skipping to change at page 32, line 12 skipping to change at page 31, line 44
o SRV records are not extensible, whereas SVCB and HTTPSSVC can be o SRV records are not extensible, whereas SVCB and HTTPSSVC can be
extended with new parameters. extended with new parameters.
o Using SRV records would not allow an HTTPS client to skip o Using SRV records would not allow an HTTPS client to skip
processing of the Alt-Svc information in a subsequent connection, processing of the Alt-Svc information in a subsequent connection,
so it does not confer a performance advantage. so it does not confer a performance advantage.
B.2. Differences from the proposed HTTP record B.2. Differences from the proposed HTTP record
Unlike [I-D.draft-bellis-dnsop-http-record-00], this approach is Unlike [I-D.draft-bellis-dnsop-http-record-00], this approach is
extensible to cover Alt-Svc and ESNIKeys use-cases. Like that extensible to cover Alt-Svc and ESNI use-cases. Like that proposal,
proposal, this addresses the zone apex CNAME challenge. 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.
B.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.draft-ietf-dnsop-aname-03], this approach is extensible
to cover Alt-Svc and ESNIKeys use-cases. This approach also does not to cover Alt-Svc and ESNI use-cases. This approach also does not
require any changes or special handling on either authoritative or require any changes or special handling on either authoritative or
master servers, beyond optionally returning in-bailiwick additional master 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
skipping to change at page 34, line 7 skipping to change at page 33, line 40
used for AliasForm RRs. used for AliasForm RRs.
C.5. Whether to include Weight C.5. Whether to include Weight
Some other similar mechanisms such as SRV have a weight in-addition Some other similar mechanisms such as SRV have a weight in-addition
to priority. That is excluded here for simplicity. It could always to priority. That is excluded here for simplicity. It could always
be added as an optional SVCB parameter. be added as an optional SVCB parameter.
Appendix D. Change history Appendix D. Change history
o draft-ietf-dnsop-svcb-httpssvc-01
* Reduce the emphasis on conversion between HTTPSSVC and Alt-Svc
* Make the "untrusted channel" concept more precise.
* Make SvcFieldPriority = 0 the definition of AliasForm, instead
of a requirement.
o draft-ietf-dnsop-svcb-httpssvc-00 o draft-ietf-dnsop-svcb-httpssvc-00
* Document an optimization for optimistic pre-connection. (Chris * Document an optimization for optimistic pre-connection. (Chris
Wood) Wood)
* Relax IP hint handling requirements. (Eric Rescorla) * Relax IP hint handling requirements. (Eric Rescorla)
o draft-nygren-dnsop-svcb-httpssvc-00 o draft-nygren-dnsop-svcb-httpssvc-00
* Generalize to an SVCB record, with special-case handling for * Generalize to an SVCB record, with special-case handling for
 End of changes. 78 change blocks. 
291 lines changed or deleted 299 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/