SVCB Service Binding Common
A modern, general-purpose record for publishing how to reach a service, including connection parameters like ALPN and ports.
What it's for
SVCB (Service Binding) is a modern DNS record type (standardized via RFC 9460, published 2023) designed to solve a problem SRV never fully solved for the web: letting a client discover not just where a service is, but how to connect to it efficiently — including which application protocols it supports (via ALPN, like HTTP/2 or HTTP/3), alternate ports, and IP address hints, all in a single DNS answer that can save round trips during connection setup.
SVCB is the general-purpose base record type; HTTPS is a specialized version of it exclusively for web traffic (and is, in practice, the one you're far more likely to actually deploy or encounter, since HTTP/HTTPS is the dominant use case this whole mechanism was built for).
Format & syntax
example.com. 3600 IN SVCB 1 svc.example.net. alpn=h2,h3 port=8443
- Priority —
0means this is an "alias mode" record (behaves like a CNAME redirect for the purposes of this lookup); any non-zero value is "service mode" and includes actual connection parameters - Target — the hostname actually providing the service (can be the same as the queried name, written as
., or a different hostname) - Parameters — key-value pairs describing connection details:
alpn(supported application protocols, likeh2,h3),port(an alternate port),ipv4hint/ipv6hint(address hints to save an extra lookup round trip), and others
How it's used in practice
- Faster HTTP/3 (QUIC) discovery — a client can learn from a single SVCB/HTTPS lookup that a server supports HTTP/3 over QUIC and connect using it directly, without first needing a slower HTTP/1.1 or HTTP/2 connection to negotiate protocol upgrade via Alt-Svc headers.
- Reducing connection setup round trips — by including IP address hints directly in the SVCB/HTTPS answer, a client can potentially skip a separate A/AAAA lookup, shaving meaningful latency off connection establishment, particularly valuable on high-latency mobile networks.
- CDN and modern hosting platform adoption — several major CDNs and hosting providers have started publishing HTTPS/SVCB records automatically as part of enabling HTTP/3 support, meaning many sites already have these records without their operators manually configuring anything.
- General service binding beyond HTTP — while HTTPS is the specialized web-focused variant, plain SVCB is meant to be usable for other protocols beyond HTTP/HTTPS as adoption grows, functioning as connection-parameter-aware SRV successor.
Common mistakes & gotchas
- Confusing SVCB with HTTPS records — for actual web traffic, the HTTPS record type is the one that matters and the one browsers actually look for; plain SVCB is the general mechanism underlying it but isn't itself queried by browsers for HTTP(S) connections.
- Assuming universal client support — SVCB/HTTPS record adoption on the client side (browsers, in particular) has grown significantly but isn't universal across every client and library; systems that don't understand these record types simply ignore them and fall back to normal A/AAAA + Alt-Svc-based discovery, so it's an enhancement rather than a hard requirement.
- Manually hand-writing complex parameter strings incorrectly — the parameter syntax (alpn lists, hints, ports) is more intricate than most record types; a malformed parameter section can cause clients that do understand SVCB to simply ignore the record rather than error loudly, making mistakes easy to miss.
- Not realizing your hosting platform may have already added these records — if you're on a modern CDN/hosting platform with HTTP/3 enabled, HTTPS/SVCB records may already exist in your zone without you having created them, which can be surprising if you're inspecting your zone file for the first time and don't recognize the record type.
Comparison & FAQ
| Type | Purpose | Key difference from SVCB |
|---|---|---|
| HTTPS | The web-specific specialization of SVCB | What browsers actually query for HTTP(S) service binding; SVCB is the general underlying mechanism |
| SRV | Older service location record (host, port, priority, weight) | SVCB is a more modern successor concept, adding richer connection parameters like ALPN and address hints that SRV never had |
What's the difference between SVCB and HTTPS records?
HTTPS is a specialized variant of SVCB specifically for web traffic, and it's the one browsers actually query. Plain SVCB is the general-purpose base mechanism, usable for protocols beyond HTTP.
Do I need to manually create SVCB records?
Often not — many modern CDN and hosting platforms publish HTTPS/SVCB records automatically as part of enabling HTTP/3 support, so you may already have them without configuring anything directly.
What happens if a client doesn't understand SVCB records?
It simply ignores them and falls back to standard A/AAAA lookups plus normal protocol negotiation (like Alt-Svc headers for HTTP/3 discovery) — SVCB is a performance enhancement, not something that breaks compatibility for clients that don't support it.
Why would SVCB improve connection performance?
By bundling connection parameters (supported protocols, alternate ports, IP address hints) into a single DNS answer, a client can potentially skip additional round trips it would otherwise need to negotiate the same information at the application layer.