# SVCB and HTTPS Record Types

Canonical: https://learndns.org/learn/8-4-svcb-https-records/

> The newest DNS record types defined in RFC 9460 — service binding, HTTPS records, eliminating redirects, and distributing ECH keys.

DNS record types haven't seen a major addition in years. [MX records](/learn/2-3-record-types/) 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:

1. **DNS lookup** for `example.com` → returns an A/AAAA record (IP address)
2. **TCP connection** to port 80
3. **HTTP request** to `http://example.com`
4. **301 redirect** to `https://example.com` (wasted round trip)
5. **New TCP connection** to port 443
6. **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)
7. **HTTP request** over TLS
8. 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:

```dns
_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:

```dns
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](/learn/7-4-common-misconfigurations/) that has forced workarounds like ANAME and ALIAS pseudo-records.

### ServiceMode (Priority 1+)

ServiceMode records carry actual connection parameters:

```dns
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:

```dns
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:

1. It's specific to HTTPS (no need for the `_https._tcp` prefix)
2. 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.

```dns
example.com.  IN HTTPS  1  .  alpn="h2,h3"
```

With this single record, the browser:

1. Knows HTTPS is supported (skip HTTP redirect)
2. Knows HTTP/2 and HTTP/3 are available (skip ALPN negotiation)
3. 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:

```http
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.

```dns
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)](/learn/8-3-encrypted-client-hello/)** keys:

```dns
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:

```dns
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.