1.1. Goals

The goal of the SVCB RR is to allow clients to resolve a single additional DNS RR in a way that:

• Provides alternative endpoints that are authoritative for the service, along with parameters associated with each of these endpoints.

• Does not assume that all alternative endpoints have 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 together multiple RRsets for the same name. For example, if www.example.com is a CNAME alias that switches between one of three Content Delivery Networks (CDNs) or hosting environments, successive queries for that name may return records that correspond to different environments.

• Enables CNAME-like functionality at a zone apex (such as example.com) for participating protocols and generally enables extending operational authority for a service identified by a domain name to other instances with alternate names.

Additional goals specific to HTTPS RRs and the HTTP use cases include:

• Connecting directly to HTTP/3 (QUIC transport) alternative endpoints [HTTP/3].

• Supporting non-default TCP and UDP ports.

• Enabling SRV-like benefits (e.g., apex aliasing, as mentioned above) for HTTP, where SRV [SRV] has not been widely adopted.

• Providing an indication signaling that the "https" scheme should be used instead of "http" for all HTTP requests to this host and port, similar to HTTP Strict Transport Security [HSTS] (see Section 9.5).

• Enabling the conveyance of Encrypted ClientHello keys [ECH] associated with an alternative endpoint.