DNS SVCB and HTTPS Records Explained: How to Advertise HTTP/3 and Improve Connection Performance

What Are SVCB and HTTPS Records?

For decades, DNS was a relatively simple lookup system. You asked where a host lived, and DNS answered with an IP address (an A or AAAA record). But as the web grew more complex — with CDNs, load balancers, and ever-more-protocols — the limitations of that simple model became obvious. Clients had to guess which protocols a server supported, and often made multiple round trips before even sending a single byte of real data.

The SVCB record (Service Binding, DNS type 64) and its special-purpose cousin, the HTTPS record (type 65), were designed to solve this. Originally outlined in draft documents and later standardized in RFC 9460, these records let a domain advertise the precise service endpoints it supports — including protocol versions, ports, and even IP address hints — all in a single DNS response.

The easiest way to think about the HTTPS record is as a set of instructions that says: "When you connect to this domain, here are the protocols I speak, the port I prefer, and a few IPs you can use right now." It turns DNS from a passive directory into an active performance advisor.

Why HTTPS Records Matter More Than Ever

The biggest driver of SVCB adoption is HTTP/3, the first major protocol to run over QUIC instead of TCP. HTTP/3 offers real benefits: dramatically faster connection establishment (often zero round trips on repeat connections), better handling of lost packets, and improved performance on high-latency or unstable networks.

But there's a catch. Historically, a browser only knew a server supported HTTP/3 after first connecting over HTTP/2 and reading an Alt-Svc header. That meant the first-time visitor had to make an entire TCP + TLS connection using the old protocol, then upgrade on the next request. The Alt-Svc approach works, but it wastes the very precious first round trips that HTTP/3 is supposed to save.

By publishing an HTTPS record, you tell browsers up front that you support HTTP/3. The browser can attempt a QUIC connection immediately, skipping the HTTP/2 handshake entirely. That's a tangible improvement in Time to First Byte (TTFB), especially on the first visit.

Anatomy of an HTTPS Record

An HTTPS record looks unusual next to an A record. Here's a real-world example, which you might see if you ran a DNS lookup against a modern, HTTP/3-enabled domain:

example.com.  3600  IN  HTTPS  1  .  alpn="h3,h2" ipv4hint="192.0.2.1" ipv6hint="2001:db8::1"

Let's break that down component by component:

• Priority: Just like with MX records, a lower number wins. If you list multiple HTTPS records, clients work through them in order.
• Target: The service endpoint name, usually the domain itself. A . means "this domain is the endpoint," which is the simplest and most common case. Alternatively, you can point at a CDN's endpoint, e.g., cdn.provider.com.
• Parameters: Key-value pairs that contain the useful service metadata:
  • alpn="h3,h2" — The Application-Layer Protocol Negotiation list. This is how you advertise HTTP/3 (the h3 identifier) alongside HTTP/2 (h2). Critically, the order matters: put your most-preferred protocol first.
  • port="8443" — A non-default port, if you use one.
  • ipv4hint="192.0.2.1" and ipv6hint="2001:db8::1" — Address hints that let clients skip an extra A/AAAA lookup. Treat these as performance hints, not authoritative addresses. A client should still verify with a standard lookup.
  • ech="..." — Encrypted ClientHello configuration, which helps close a long-standing privacy gap in the TLS handshake.

Alias Mode vs. Service Mode

When the target is a ., the record is said to be in service mode: the domain itself is providing the service, and the parameters apply directly. When the target names another domain (such as a CDN like global.fastly.net), it is called alias mode. In alias mode, the client follows the target to find the real HTTPS or SVCB record, which often means handshaking with that target directly for the connection.

For a solo website operator using their own infrastructure, service mode with alpn and IP hints is the gold standard. For anyone sitting behind a CDN or a reverse proxy, you'll likely need to coordinate with that provider — many of the large CDNs now publish HTTPS records on their side automatically.

Practical Tips for Implementing HTTPS Records

If you want to start advertising HTTP/3 for your domain, here is a practical playbook:

1. Verify Your DNS Provider Supports the Record Type

Historically, many DNS providers treated unknown record types as an error. Modern providers like Cloudflare, Route 53, and Google Cloud DNS support SVCB and HTTPS records natively. But if you're using a long-tail registrar's basic nameservers, you may need to migrate or add a DNS layer. Always check the documentation before publishing, or at least validate the record after creation with your preferred DNS lookup tool — a DNS Analyzer is ideal for confirming your record is visible and syntactically correct from multiple locations.

2. Get HTTP/3 Working Before You Advertise It

Don't publish alpn="h3,h2" until your server genuinely speaks HTTP/3/QUIC. Modern web servers like nginx, Caddy, and Apache (via module) all support HTTP/3, but configuration varies, and you need to open UDP port 443 in addition to the traditional TCP port 443. Test thoroughly once, then check your configuration with a tool like the SSL Checker to ensure your certificate chain is valid over both transports.

A good interim step is the Alt-Svc approach, where browsers learn about HTTP/3 opportunistically. Once you've validated that it works reliably at scale, add the HTTPS record and let new visitors connect directly to HTTP/3 from the start.

3. Mind Your ALPN Order

The alpn list must include all the protocols you support, and it should be ordered by preference. If you prefer HTTP/3 but want HTTP/2 as a graceful fallback, use alpn="h3,h2". Some implementations also allow the special token alpn="h2,h3", which tells the client you're happy with either but in a specific order of preference, enabling "Happy Eyeballs"-style racing between QUIC and TCP+TCP+TLS.

4. Use Address Hints With Care

ipv4hint and ipv6hint are exactly what they say: hints. In your own load-balanced environment, keeping the hints stable is important. If you update your backend IPs without updating your HTTPS record, clients may connect to a stale address — though the spec mandates they should retry using canonical A/AAAA records. In practice, browsers are fairly lenient here, but you should still treat your hints with the same care as your glue records.

5. Understand Fallback Behavior

The most reassuring property of SVCB records is that they degrade gracefully. If a client doesn't understand HTTPS records, it ignores them entirely and falls back to traditional A/AAAA + ALPN negotiation. If your HTTPS record fails validation mid-connection, clients perform connection fallback rather than giving up. This makes the record safe to deploy incrementally, but it also means you owe it to your users to keep the record accurate — a bad record won't break your site, but it can degrade performance for everyone until it's fixed.

A Look at the Broader DNS Ecosystem

While the HTTPS record is the one most website owners will interact with, the underlying SVCB mechanism is generic. The same RFC 9460 pattern can advertise endpoints for email, instant messaging, and any other dot-prefixed service you can register. One practical consequence: service discovery for non-HTTP protocols is finally modernizing.

Also, note that HTTPS records work alongside other security and performance technologies. For example, DNSSEC protects the integrity of your HTTPS records, and you should sign your zone if you haven't already. An attacker who could forge your SVCB record would be able to redirect clients to their own server, so treat these records with the same integrity protections as your existing DNS.

How to Test Your Implementation

Before cutting over, run a query for the HTTPS record type to see what the world sees. Using the dig command, you can query a domain directly:

dig HTTPS example.com +short

You should get back output similar to the example earlier in this article. If your provider doesn't expose the HTTPS record over traditional DNS, you'll likely need to switch to a provider that does. After publishing, verify latency improvements by comparing TTFB over HTTP/2 versus HTTP/3 in Chrome's DevTools (look for an h3 entry in the protocol column of the network tab) or via online HTTP/3 checkers.

Final Thoughts

DNS SVCB and HTTPS records are one of the most meaningful DNS innovations in years — not because they replace existing records, but because they give operators control over protocol negotiation at the very earliest point of a connection. If you serve a high-traffic site, or just want your visitors to experience the fastest possible first page load, implementing an HTTPS record is one of the smartest low-effort optimizations available today.

Start small, test carefully, and let the record point browsers toward the fast lane while the robust, decades-old fallbacks handle the rest.