DNS record types haven’t seen a major addition in years. MX records date to 1986. SRV records arrived in 2000. Then, for over two decades, DNS added nothing fundamentally new to how clients discover services. That changed with RFC 9460, published in November 2023, which introduced two new record types: SVCB (Service Binding) and HTTPS.
These records solve real problems that the web has been working around for years — and they’re already being deployed at scale.
The Problem: How Clients Connect Today
When your browser navigates to http://example.com, a cascade of inefficiencies begins:
- DNS lookup for
example.com→ returns an A/AAAA record (IP address) - TCP connection to port 80
- HTTP request to
http://example.com - 301 redirect to
https://example.com(wasted round trip) - New TCP connection to port 443
- TLS handshake (the browser doesn’t yet know which ALPN protocols the server supports, whether HTTP/2 or HTTP/3 is available, or where the ECH keys are)
- HTTP request over TLS
- Potentially another redirect if the server wants to send you to
www.example.com
That’s at minimum two wasted round trips before any real content loads. The HTTP-to-HTTPS redirect alone adds 50-200ms of latency for every first visit. Multiply that across billions of page loads per day.
SRV records could theoretically solve some of this, but browsers never adopted them for HTTP. The HTTPS and SVCB record types were designed specifically to fix this.
SVCB: The General-Purpose Service Binding Record
SVCB (Service Binding) is a general-purpose DNS record type for advertising how to connect to a service. It provides connection parameters — ports, protocols, keys — directly in DNS, eliminating the need for trial-and-error connection establishment.
A SVCB record has three components:
_service._proto.name. IN SVCB priority target params
- Priority: 0 for AliasMode (like CNAME), 1-65535 for ServiceMode (direct connection info)
- Target: The hostname to connect to (
.means “same as the query name”) - Params: Key-value pairs describing connection parameters
AliasMode (Priority 0)
When the priority is 0, the SVCB record works like an enhanced CNAME — it redirects to another name for service information:
example.com. IN SVCB 0 edge.cdn.example.net.
This tells the client: “Go look up SVCB records for edge.cdn.example.net to find out how to connect.” Unlike CNAME, AliasMode SVCB records can coexist with other record types at the zone apex. This solves the long-standing “CNAME at apex” problem that has forced workarounds like ANAME and ALIAS pseudo-records.
ServiceMode (Priority 1+)
ServiceMode records carry actual connection parameters:
example.com. IN SVCB 1 . alpn="h2,h3" port=8443 ipv4hint=192.0.2.1
This tells the client: “Connect to example.com on port 8443, supporting HTTP/2 and HTTP/3, and try IP address 192.0.2.1.”
Multiple ServiceMode records with different priorities enable failover:
example.com. IN SVCB 1 primary.example.com. alpn="h2,h3"
example.com. IN SVCB 2 backup.example.com. alpn="h2"
HTTPS Records: SVCB for the Web
The HTTPS record type is a specialization of SVCB specifically for HTTPS services. It’s functionally identical to SVCB but with two key differences:
- It’s specific to HTTPS (no need for the
_https._tcpprefix) - It implicitly signals that the service supports HTTPS, enabling browsers to skip the HTTP→HTTPS redirect
Eliminating the HTTP-to-HTTPS Redirect
This is the most immediately impactful feature. When a browser resolves example.com and receives an HTTPS record, it knows the site supports HTTPS before making any connection. It can go directly to https://example.com, skipping the insecure HTTP request and redirect entirely.
example.com. IN HTTPS 1 . alpn="h2,h3"
With this single record, the browser:
- Knows HTTPS is supported (skip HTTP redirect)
- Knows HTTP/2 and HTTP/3 are available (skip ALPN negotiation)
- Can establish the optimal connection on the first try
The latency savings are 100-300ms per first visit — significant at scale.
Alt-Svc vs HTTPS Records
HTTP/2 introduced Alt-Svc (Alternative Service) headers to advertise HTTP/3 availability:
Alt-Svc: h3=":443"; ma=86400
But Alt-Svc has a bootstrapping problem: you only receive it after connecting via HTTP/2. The first connection can’t use HTTP/3. Subsequent visits can, if the browser cached the Alt-Svc header — but cache expiration and new users always fall back to HTTP/2 first.
HTTPS records solve this by advertising HTTP/3 support in DNS, before any connection. A browser that sees alpn="h3" in the HTTPS record can attempt a QUIC/HTTP/3 connection immediately, with HTTP/2 as a fallback.
example.com. IN HTTPS 1 . alpn="h3,h2" ipv4hint=192.0.2.1 ipv6hint=2001:db8::1
This combination — HTTPS record with ALPN and address hints — gives the browser everything it needs to establish the optimal connection in a single DNS lookup.
ECH Key Distribution
As discussed in the previous chapter, HTTPS records are the distribution mechanism for Encrypted Client Hello (ECH) keys:
example.com. IN HTTPS 1 . alpn="h2,h3" ech="AEX+DQBBq..."
The ech parameter contains the public key configuration that the client uses to encrypt the ClientHelloInner. This coupling of ECH with HTTPS records is by design — it ensures that ECH keys are delivered alongside other connection parameters, and that the same DNS query that resolves the domain also provides the privacy-enhancing encryption keys.
This is why the deployment of HTTPS records and ECH are linked: you can’t deploy ECH without HTTPS records (there’s no other standardized distribution mechanism), and HTTPS records naturally carry ECH keys alongside other parameters.
Service Parameters (SvcParams)
SVCB and HTTPS records support a growing set of parameters:
| Parameter | Key | Purpose |
|---|---|---|
alpn |
1 | Application-Layer Protocol Negotiation (h2, h3) |
no-default-alpn |
2 | Don’t assume default protocols |
port |
3 | Non-standard port number |
ipv4hint |
4 | IPv4 address hints (avoid extra A lookup) |
ech |
5 | Encrypted Client Hello configuration |
ipv6hint |
6 | IPv6 address hints (avoid extra AAAA lookup) |
ohttp |
8 | Oblivious HTTP target configuration |
The ipv4hint and ipv6hint parameters are particularly clever. They include IP addresses directly in the SVCB/HTTPS record, allowing the client to begin connecting before the separate A/AAAA lookups complete. These are hints, not authoritative — the client should still perform the A/AAAA lookups, but it can race them against a connection attempt using the hints.
The ohttp parameter supports Oblivious HTTP (OHTTP), a protocol that adds another privacy layer by proxying requests through an intermediary that can’t see the content. OHTTP configuration in DNS records follows the same pattern as ECH: distribute the keys via DNS, use them at connection time.
Adoption Status
SVCB and HTTPS record adoption is accelerating:
Cloudflare automatically generates HTTPS records for all domains on its platform, including ALPN, address hints, and ECH keys where supported. Given Cloudflare’s market share, this alone puts HTTPS records on a significant percentage of the web.
Apple was an early adopter, publishing HTTPS records for icloud.com, apple.com, and other properties.
Google has rolled out HTTPS records across its infrastructure, including google.com and YouTube.
Authoritative DNS providers — including Cloudflare DNS, Google Cloud DNS, AWS Route 53, and NS1 — all support HTTPS record types.
Browser support is strong in Chrome and Firefox, which query for HTTPS records by default and use the results to optimize connections. Safari also supports HTTPS records.
Resolver support is nearly universal among major public resolvers. Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9) all handle HTTPS queries correctly.
The main adoption gap is on the origin server side — many site operators haven’t added HTTPS records to their DNS because the benefits accrue automatically for sites behind CDNs (which add the records themselves), and smaller sites may not know the records exist.
What This Means for DNS
SVCB and HTTPS records represent a philosophical shift in what DNS does. Traditionally, DNS answered one question: “What’s the IP address?” Now it answers: “How should I connect, what protocols are supported, what keys should I use, and where should I go?”
DNS is evolving from a name resolution system to a service discovery system. This is the same trajectory that led to SRV records, but SVCB/HTTPS records are the first to achieve widespread browser adoption for web services.
For DNS operators, this means zone files are getting more complex. A modern zone might include:
example.com. IN A 192.0.2.1
example.com. IN AAAA 2001:db8::1
example.com. IN HTTPS 1 . alpn="h3,h2" ech="AEX+..." ipv4hint=192.0.2.1
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN MX 10 mail.example.com.
Each record type serves a different purpose, and HTTPS records add the richest connection metadata yet. As more parameters are standardized — OHTTP, future protocol extensions — the HTTPS record will continue to grow in importance.
The web is getting faster, more private, and more efficient. SVCB and HTTPS records are a quiet but significant part of that story.