| Internet-Draft | Alt-Svc via DNS | September 2023 |
| Schwartz & Bishop | Expires 29 March 2024 | [Page] |
The HTTP Alternative Services (Alt-Svc) mechanism allows an HTTP origin to be served from multiple network endpoints, and over multiple protocols. However, the client must first contact the origin server, in order to learn of the alternative services. This draft proposes a straightforward mapping of Alt-Svc into DNS, allowing clients to learn of these services before their first contact with the origin. This arrangement offers potential benefits to both performance and privacy.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 29 March 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The HTTP Alternative Services standard [AltSvc] defines¶
Together, these components provide a toolkit that has proven useful and effective for informing a client of alternative services for an origin. However, making use of an alternative service requires contacting the origin server first. This creates an obvious performance cost: users wait for a full HTTP connection initiation (multiple roundtrips) before learning of an alternative service that is preferred by the origin. The first connection also publicly reveals the user's intended destination to all entities along the network path.¶
This draft proposes a straightforward mechanism to distribute the Alt-Svc Field Value, in its standard text format, through the DNS. If a client receives this information during DNS resolution, it can skip the initial connection and proceed directly to an alternative service.¶
For consistency with [AltSvc], we adopt the following definitions¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The ALTSVC DNS resource record (RR) type (RRTYPE ???) is used to associate an Alternative Service Field Value with an origin. Abstractly, the origin consists of a scheme (typically "https"), a host name, and a port (typically "443").¶
In the case of the ALTSVC RR, the origin is represented by prefixing the port and scheme with "_", then concatenating them with the host, resulting in a domain name like "_443._https.www.example.com.".¶
The IANA DNS Underscore Global Scoped Entry Registry [Attrleaf] MUST have an entry under the ALTSVC RRType for this scheme. The scheme SHOULD have an entry in the IANA URI Schemes Registry [RFC7595]. The scheme SHOULD be one for which Alt-Svc is defined (currently "http" or "https").¶
The RDATA portion of an ALTSVC resource record contains an Alt-Svc Field Value, exactly as defined in Section 4 of [AltSvc].¶
For example, if the operator of https://www.example.com intends to include an HTTP response header like¶
Alt-Svc: h2=":8000"; ma=60¶
They would also publish an ALTSVC DNS record like¶
_443._https.www.example.com. 60S IN ALTSVC "h2=\":8000\""¶
This data type can be represented as an Unknown RR as described in [RFC3597]:¶
_443._https.www.example.com. 60S IN TYPE??? \# 10 68323D223A3830303022¶
This construction is intended to be extensible in two ways. First, any extensions that are made to the Alt-Svc format for transmission over HTTPS are also applicable here, unless expressly mentioned otherwise. Second, including the scheme in the DNS name allows for ALTSVC to serve schemes other than HTTPS, such as HTTP with Opportunistic Security [RFC8164] and any future schemes for which Alt-Svc may be defined.¶
The ALTSVC record type closely resembles some existing record types.¶
An SRV record can perform a similar function to the ALTSVC record, informing a client to look in a different location for a service. However, there are several differences:¶
The ALTSVC record uses an identical format to a TXT record, and could be implemented as such. However, we define a new record type for clarity, and to respect the use of TXT for human-readable notes as recommended in [RFC5507].¶
Publishing an ALTSVC record in DNS is intended to be equivalent to transmitting this field value over HTTP, and receiving an ALTSVC record is intended to be equivalent to receiving this field value over HTTP. However, there are some small differences in the intended client and server behavior.¶
When publishing an ALTSVC record in DNS, server operators MUST omit the "ma" parameter, which encodes the "max age" (i.e. expiration time) of an Alt-Svc Field Value. Instead, server operators SHOULD encode the expiration time in the DNS TTL, and MUST NOT set a TTL longer than the intended "max age".¶
When receiving an ALTSVC record, clients MAY synthesize a new "ma" parameter from the DNS TTL, in order to interoperate with Alt-Svc processing subsystems.¶
Server operators MAY publish multiple ALTSVC records as an RRSET. When publishing an RRSET with multiple ALTSVC records, the server operator MUST set the overall TTL to the minimum of the "max age" values (following Section 5.2 of [RFC2181]). Each RR can contain multiple alt-values separated by commas, as described in Section 3 of [AltSvc]. As specified there, "the order of values relects the server's preference".¶
When receiving an RRSET containing multiple ALTSVC records, clients SHOULD apply a random shuffle to the records before using them, to ensure randomized load-balancing. This is consistent with DNS rules for interpretation of RRSETs, which are regarded as unordered collections.¶
After shuffling the RRSET, the client SHOULD concatenate all the values 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]).¶
The purpose of this standard is to reduce connection latency and improve user privacy. Server operators implementing this standard SHOULD also implement TLS 1.3 [I-D.ietf-tls-tls13] and OCSP Stapling [RFC6066], both of which confer substantial performance and privacy benefits when used in combination with ALTSVC records.¶
To realize the greatest privacy benefits, this proposal is intended for use with a privacy-preserving DNS transport (like DNS over TLS [RFC7858] or DNS over HTTPS [DOH]), and with the "SNI" Alt-Svc Parameter [AltSvcSNI]. However, performance improvements, and some modest privacy improvements, are possible without the use of those standards.¶
Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc Field Value specifically to the client. When using an ALTSVC DNS record, groups of clients will necessarily receive the same Alt-Svc Field Value. Therefore, this standard is not suitable for servers that require single-client granularity in Alt-Svc. Server operators that want to serve different Alt-Svc Field Values to different geographic or network regions SHOULD configure their authoritative DNS server to respect the EDNS0 Client Subnet extension [RFC7871].¶
Some DNS caching systems incorrectly extend the lifetime of DNS records beyond the stated TTL. Server operators MUST NOT rely on ALTSVC records expiring on time, and MAY shorten the TTL to compensate.¶
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 ALTSVC 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 ALTSVC query to refresh the entry.¶
Clients that are optimizing for performance (i.e. minimum connection setup time) SHOULD implement the following connection sequence:¶
If the ALTSVC and address queries return approximately simultaneously, this process typically saves three roundtrips on a fresh connection that uses Alt-Svc: one each for TCP, TLS 1.3, and HTTP. (On subsequent connections, the Alt-Svc information is expected to be cached, so this procedure does not apply.)¶
If a client can cache Alt-Svc entries that were received over both HTTP and DNS, the client MAY prefer entries that were received over HTTP. These records may be more narrowly targeted for the specific client.¶
As an additional optimization, when choosing among multiple Alt-Svc values, clients MAY prefer those that will not require an address query, either because the corresponding address record is already in cache or because the host is an IP address.¶
Note that this procedure does not rely on recursive resolvers handling the ALTSVC record type correctly. If ALTSVC queries receive spurious NXDOMAIN responses, or even no response at all, connections will proceed as usual without any delay.¶
Clients that are optimizing for privacy SHOULD implement [AltSvcSNI] and DNS over a secure transport (e.g. [RFC7858] or [DOH]). Use of a secure transport is important not only for privacy protection, but also to ensure that queries for the new ALTSVC RRTYPE are handled correctly. Additionally, these clients SHOULD implement the following connection sequence:¶
Note that this process is also expected to be faster than Alt-Svc over HTTP in the case of HTTP Opportunistic Upgrade Probing (Section 2 of [RFC8164]).¶
Alt-Svc Field Values are intended for distribution over untrusted channels, and clients are REQUIRED to verify that the alternative service is authoritative for the origin (Section 2.1 of [AltSvc]). Therefore, DNSSEC signing and validation are OPTIONAL for publishing and using ALTSVC records.¶
Per [RFC6895], please add the following entry to the data type range of the Resource Record (RR) TYPEs registry:¶
| TYPE | Meaning | Reference |
|---|---|---|
| ALTSVC | Alt-Svc Value | (This document) |
Per [Attrleaf], please add the following entries to the DNS Underscore Global Scoped Entry Registry:¶
| RR TYPE | _NODE NAME | Meaning | Reference |
|---|---|---|---|
| ALTSVC | _https | Alt-Svc for HTTPS | (This document) |
| ALTSVC | _http | Alt-Svc for HTTP | (This document) |