HTTPS vs SVCB Records

SVCB (Service Binding) and HTTPS are a pair of DNS record types defined together in RFC 9460. Both let a domain publish service parameters, the details a client needs to connect well, directly in DNS. Instead of connecting first and negotiating capabilities afterward, a client can read these records up front and choose the best protocol and endpoint immediately.

The two records share one format and purpose. The difference is scope: SVCB is the general mechanism, and HTTPS is a ready-made specialization of it for the web.

An SVCB record is the general-purpose form. It can describe how to reach any service, not just web servers, and is published under a name that encodes the service and protocol, much like an SRV record:

Each record carries a priority and a target, plus a set of key-value parameters describing the connection. SVCB is the foundation; new protocols can define their own bindings on top of it without inventing entirely new record types.

An HTTPS record is SVCB applied specifically to web traffic. Because the service (HTTPS) is already implied, it is published directly on the hostname with no service or protocol prefix, and browsers know to query it automatically:

This example advertises support for HTTP/3 and HTTP/2 via the alpn parameter. The HTTPS record is the form most domains will actually use, since the web is where these records deliver the clearest benefit.

The cleanest way to think about it is that HTTPS is a preconfigured SVCB record for the web. SVCB is the generic engine, and HTTPS is the specific application of that engine to HTTP over TLS. They use the same wire format and the same parameters, so learning one teaches you the other.

• Scope. SVCB serves any protocol; HTTPS serves web traffic only.
• Naming. SVCB sits under a service and protocol label; HTTPS sits directly on the hostname.
• Discovery. Browsers query the HTTPS record automatically; SVCB is queried by whatever protocol defines its use.

Both records exist to make connections faster and more secure from the very first packet:

• Faster connection setup. Clients learn the right protocol and endpoint from DNS, avoiding extra round trips and redirects.
• HTTP/3 hints. The alpn parameter lets a site advertise HTTP/3 directly, so clients can use it immediately instead of upgrading later.
• Encrypted Client Hello. The records can carry ECH keys, allowing the server name in the TLS handshake to be encrypted for better privacy.
• Alternative endpoints and ports. A single record can steer clients to a better target or a non-standard port.

For a refresher on how any of these records is resolved in the first place, see what is DNS.