DNS HTTPS Record Type (SVCB): Bootstrapping Connections to CDN Edges

Last winter I was debugging a slow TTFB spike for a large e-commerce customer on our edge. Their origin was fine, their cache hit ratio was 98%, yet users on Chrome 118 were seeing an extra 120ms on cold starts. The culprit wasn’t the CDN logic at all — it was the classic dance: DNS A lookup, then AAAA, then ALPN negotiation, then TLS. We’d already deployed HTTPS records for a subset of zones, and the zones without them were paying that tax on every fresh connection. That’s when connection bootstrapping with SVCB stopped being a spec curiosity and became a production necessity.

Why SVCB and HTTPS Records Had to Happen

For decades we’ve overloaded A and AAAA records to mean “where to connect,” but we never told the client “how to connect.” The browser had to resolve the name, open a TCP socket, then ask the server what it supports via ALPN. If the site supported HTTP/3, Encrypted Client Hello, or even a non-standard port, the client wouldn’t know until after it had already wasted a round trip. I’ve spent too many nights explaining to customers why their perfectly tuned anycast edge still saw suboptimal handshake times — the DNS layer simply wasn’t expressive enough.

The SVCB and HTTPS record types, standardized as types 64 and 65, solve that by collapsing service configuration into DNS itself. Think of HTTPS as a specialized SVCB record for the https:// scheme. A client that understands it gets SvcParams right alongside the address hints: supported ALPNs, IP hints, port, ECH keys, and whether the name is in AliasMode or ServiceMode. If you’ve dealt with DNS CNAME Flattening: Pointing Root Domains to CDN Without Breaking DNS Rules, you know how fragile workarounds for the apex get. HTTPS records give us a standards-based way to alias or bind services without the CNAME-at-apex violation, and they do it with authenticated metadata.

There are two modes that trip people up. Priority 0 means AliasMode — it behaves like a secure, SVCB-aware CNAME. The client must follow the TargetName and re-query. Priority 1+ means ServiceMode — the record itself is authoritative for connection parameters. At our edge we almost exclusively publish ServiceMode with Priority 1, because we want the client to use the hints immediately. Clients that don’t understand the type just ignore it and fall back to A/AAAA, so deployment is safely incremental. The details and parameter registry are well documented in the HTTP Working Group Specifications and the SVCB draft.

# Querying an HTTPS record directly - try this against a CDN-enabled zone
dig HTTPS shop.example.com +noall +answer

; shop.example.com.  300 IN  HTTPS 1 . alpn="h3,h2" ipv4hint=192.0.2.1,192.0.2.2 \
;                          ipv6hint=2001:db8::1 ech="AEX+DQBB.../w=="
; Fallback for legacy resolvers - still need A/AAAA
dig A shop.example.com +short
192.0.2.1
192.0.2.2

Bootstrapping CDN Edges Without Wasting Round Trips

Here’s how it actually changes the connection flow on a modern CDN. Without HTTPS records, a Chrome or Firefox client does: 1) resolve A/AAAA, 2) TCP handshake, 3) TLS ClientHello without ECH and with a guess at ALPN, 4) server responds with its ALPN preference, 5) maybe retries with HTTP/3 after Alt-Svc. With HTTPS records, step 1 returns everything. The resolver response already says “you can reach me at these IP hints, speak h3 and h2, and here’s my ECH public key.” The client can send its first ClientHello with ECH encrypted, using the correct ALPN, and even elide the A/AAAA lookup entirely if it trusts the hints.

That last part is critical for edge performance. ipv4hint and ipv6hint aren’t a replacement for A/AAAA — they’re a head start. We publish them with a 60-300 second TTL alongside our anycast addresses, so a recursing resolver can give the client a routable address in the same response as the service binding. I learned this the hard way when we first rolled out hints with a 30-minute TTL and forgot to automate rotation during an edge expansion. Clients cached stale hints and tried to connect to decommissioned PoPs for minutes. Now we tie hint generation to our control plane and keep TTLs short, similar to how we handle DNS NS Delegation for CDN: Offloading Domain Resolution to Edge Networks where delegation changes must propagate quickly.

The other win is pairing HTTPS records with Encrypted Client Hello and HTTP/3 advertisement. Before, advertising h3 required either an Alt-Svc header (which needs a first connection) or a manual HTTP/3 discovery. Now alpn="h3,h2" in the HTTPS record tells the client before the first socket opens. Combined with EDNS Client Subnet for CDN Geolocation: Routing Users to the Nearest Edge, our authoritative DNS can still return geo-tailored hints, but the client doesn’t need to pay for an extra fetch to learn it should use QUIC. The web.dev Articles have excellent data showing how this reduces connection error rates on lossy mobile networks.

; Full ServiceMode HTTPS record as we publish it at the edge
; Zone file syntax (BIND / CoreDNS compatible)
shop.example.com.  60 IN HTTPS 1 . (
    alpn="h3,h2" 
    port=443
    ipv4hint=192.0.2.10,192.0.2.11
    ipv6hint=2001:db8:1::10,2001:db8:1::11
    ech="AEb+DQBCa... base64 ECHConfig ..."
    no-default-alpn )

; AliasMode example - delegating to the CDN's canonical name
; Client will re-query for cdn.example.net's HTTPS record
www.example.com.  300 IN HTTPS 0 cdn.example.net.

What We Measured After Enabling HTTPS Records at the Edge

We rolled out HTTPS records to about 40% of our traffic in Q2 last year, starting with browser-heavy properties that already had high HTTP/3 support. The setup was simple: our authoritative servers started signing and serving type 65 alongside A/AAAA, with automatic ECH key rotation every 72 hours. We didn’t change anycast routing, congestion control, or TLS configs — just the DNS bootstrap. That isolation made the A/B comparison pretty clean, and the results were consistent enough that we moved to 100% within two months.

The biggest surprise wasn’t the median improvement, it was the P95 story on mobile. Clients on high-RTT networks benefited disproportionately because we eliminated a full DNS round trip and an ALPN negotiation failure. Users who would have fallen back from a failed h3 attempt over TCP now started directly on QUIC when the network supported it. We also saw a measurable drop in failed handshakes where middleboxes interfered with ClientHello — ECH via the HTTPS record encrypted the SNI before the first packet left the device.

If you’re planning your own rollout, don’t treat ipv4hint as authoritative. We still require a valid A record and we monitor coherence between hints and the actual edge addresses. We also log SvcParam validation failures from clients that don’t support mandatory keys. Keep your TTLs under 300 seconds if your edge IPs churn, and test AliasMode vs ServiceMode carefully — AliasMode adds a follow-up query that can erase the latency win if your TargetName isn’t also HTTPS-enabled.

Deploying HTTPS Records in Production: From Zone File to Edge

Getting HTTPS records live isn't just flipping a switch in your DNS provider's dashboard — though that's how we started. For most CDNs, the real work is wiring your authoritative DNS pipeline to generate ServiceMode records dynamically per edge PoP, not serving a static record you hand-edited once. We template ours at the control plane. When a customer onboards `cdn.example.com`, we automatically publish an HTTPS record with priority 1 that advertises `alpn="h3,h2"` and includes `ipv4hint` and `ipv6hint` for the anycast / geo-mapped edge IPs closest to the requesting resolver's network. That cuts out the extra A/AAAA lookup entirely for clients that support it — Chrome, Firefox, and Safari all do now — and we've seen it shave 35-60ms off time-to-first-byte on high-latency mobile networks.

You'll want to be explicit about your ALPN and port targeting, and don't forget that `ech` is now part of the story if you're doing Encrypted Client Hello. A common mistake we see is publishing HTTPS records without DNSSEC Signing for CDN Infrastructure: Authenticated DNS Without the Performance Hit — if you're bootstrapping security parameters via DNS, you really need that authentication chain. Unsigned HTTPS records with ECH keys are just begging to be spoofed. We sign all our HTTPS/SVCB records with ECDSAP256SHA256 and keep TTLs at 300 seconds; it's short enough to fail over quickly when we drain a PoP, but long enough that resolvers aren't hammering us. Cloudflare and Google Public DNS both respect that TTL correctly, but we've seen some enterprise resolvers cap it at 60s no matter what you publish.

; ServiceMode HTTPS record for CDN edge bootstrapping
; Priority 1 = ServiceMode (not AliasMode)
cdn.example.com.  300  IN  HTTPS  1 . alpn="h3,h2" port=443 ipv4hint=192.0.2.10,192.0.2.11 ipv6hint=2001:db8::10 ech="AE3+DQB2a...base64..."

; AliasMode example - apex to CDN canonical
example.com.      300  IN  HTTPS  0 cdn.example.com.

; SVCB for non-HTTPS origin (e.g., custom alt service)
_api.example.com. 300  IN  SVCB   1 api.edge.cdn.net. alpn="h2" port=8443 ipv4hint=192.0.2.20

That first record is the workhorse. Priority `1` with target `.` means "I'm the service endpoint itself," and the `alpn` hints tell the client it can go straight to HTTP/3 without negotiating down from h2. The `ipv4hint`/`ipv6hint` fields are the real performance win — they let supporting clients start the QUIC or TCP handshake in parallel with the DNS resolution. We've measured connection setup dropping from 3 round trips (DNS + TCP + TLS) to effectively 1.2 on warm resolvers. If you're using BIND, Knot, or PowerDNS, make sure you're on a version that actually supports HTTPS type 65 — BIND 9.18+, Knot 3.1+, PowerDNS Auth 4.7+ — otherwise it'll silently serve it as a generic TYPE65 and some resolvers will choke.

Advanced Patterns and Troubleshooting When SVCB Breaks

Once you've got the basics working, AliasMode is where things get interesting for CDN architectures. We use `HTTPS 0` at the apex to alias `example.com` to `example.com.cdn.provider.net.` without a CNAME — which matters because you can't CNAME at the apex, and HTTPS AliasMode finally solves that 30-year-old DNS wart. Clients that understand it follow the alias and then use the ServiceMode record at the target; clients that don't just fall back to A/AAAA like nothing happened. That's the beauty of it — it's fully backward compatible. We've also started using SVCB for origin discovery internally, so our edge can locate the optimal origin shield via `SvcPriority` weighting instead of hardcoding origins in config.

When it breaks, it breaks quietly, so you need to know where to look. The number one issue we debug is malformed `ech` or `ipv6hint` causing clients to hard-fail instead of fallback. Chrome will fail closed if you publish an ECH key that's expired or incorrectly base64-encoded — it won't just ignore it. Use `dig https cdn.example.com +short` and `kdig --type=HTTPS` to validate what you're actually serving versus what you think your API pushed. And keep an eye on your authoritative DNS load. HTTPS records are larger — often 180-250 bytes versus 32 bytes for an A record — so if you're not careful, you'll push responses over the 1,232-byte UDP safe limit and force TCP fallback. We had to enable DNS response compression and trim unnecessary hints for dual-stack records to stay under that limit. If you're seeing a spike in TCP DNS queries or truncated responses, that's your clue. It's the same operational discipline you need for DNS Amplification Attack Mitigation: Protecting CDN DNS Infrastructure — large records are great for performance, but they're also great for reflectors if you leave your infrastructure open.

Another pattern we rely on heavily is using HTTPS records for controlled traffic steering and abuse mitigation. Instead of returning different A records via GeoDNS, we can return different `ipv4hint` sets based on client subnet (via EDNS Client Subnet) and even signal that a specific PoP is in maintenance mode by lowering its priority or removing its hint. For customers under active attack, we've paired HTTPS record updates with DNS Sinkholing at CDN Scale: Redirecting Malicious Traffic for Analysis — we publish a high-priority HTTPS record that points suspicious client subnets to a scrubbing edge with `alpn="h2"` only, while clean traffic gets the full `h3` path. It lets us quarantine without touching the customer's origin config at all, and because the TTL is 300s, we can revert in under five minutes once the attack subsides.

Frequently Asked Questions