savearoundtrip

check a domain

This site eats its own dog food: savearoundtrip.com publishes an HTTPS record with h3, IP hints, and ECH.

The HTTPS record is looked up in your browser via Cloudflare's DNS-over-HTTPS endpoint. The Alt-Svc header and a live HTTP/3 handshake can't be checked from a browser (CORS hides cross-origin headers, and a browser can't force a cold QUIC connection), so the domain you enter is sent to a small open-source backend that runs only those two checks. Nothing is stored.

The live HTTP/3 handshake is performed with quic-go.

what a round trip costs

A round trip is one message to the server and back, bounded by the speed of light: roughly 5 to 20 ms within a city, 40 to 80 ms across a country, and 150 ms or more across an ocean or a mobile network (Cloudflare Radar has live numbers). It is paid where people notice: under about 100 ms an interaction feels instantaneous; past that it feels like waiting (Nielsen Norman Group).

the wasted round trip

Alt-Svc (RFC 7838) is an HTTP response header. To read it, the client must finish a request, which means it has already opened a TCP connection, done a TLS handshake, and spoken HTTP/1.1 or HTTP/2. Only then does it learn "by the way, I also speak HTTP/3". The HTTP/3 upgrade lands on the next connection.

An HTTPS record (RFC 9460) carries the same "I speak HTTP/3" signal, but in the DNS. The client reads it during the name resolution it was going to do anyway, before it opens any connection. So it can make its very first connection over QUIC/HTTP/3, with no earlier HTTP/1 or HTTP/2 connection spent just to find out.

sequenceDiagram
    participant C as Client
    participant D as DNS
    participant S as Your server
    Note over C,S: First connection
    C->>D: look up A / AAAA
    D-->>C: IP address
    C->>S: TCP SYN
    S-->>C: SYN-ACK
    C->>S: TLS ClientHello
    S-->>C: TLS ServerHello, Finished
    C->>S: HTTP/2 request
    S-->>C: response + Alt-Svc: h3
    Note over C,S: only now does the client learn you speak HTTP/3
    Note over C,S: Second connection
    C->>S: QUIC + HTTP/3 handshake
    S-->>C: connected (HTTP/3)
        

sequenceDiagram
    participant C as Client
    participant D as DNS
    participant S as Your server
    Note over C,S: First connection
    C->>D: look up HTTPS record
    D-->>C: alpn=h3 + IP hints (+ ECH)
    C->>S: QUIC + HTTP/3 handshake
    S-->>C: connected (HTTP/3)
    C->>S: HTTP/3 request
    S-->>C: response
        

why the HTTPS record is strictly better

The HTTPS resource record (RFC 9460, Nov 2023) folds everything a client needs to open the optimal connection into the DNS answer it was already fetching. Concretely:

1 · HTTP/3 discovery before the first byte

The alpn SvcParam lists the ALPN protocol IDs the endpoint speaks, e.g. h3 (HTTP/3) and h2. Because it arrives during name resolution, the client can pick QUIC for its very first connection instead of discovering h3 only after a previous HTTP/1 or HTTP/2 connection.

2 · ECH: Encrypted Client Hello (only the DNS can deliver it)

The ech SvcParam carries the endpoint's ECHConfigList public keys (RFC 9849). ECH encrypts the TLS ClientHello, including the SNI server name, so a network observer can't see which site you're visiting. This is a chicken-and-egg problem an HTTP header can't solve: you need the public key before you send the first ClientHello, which is exactly when no connection exists yet. Only an out-of-band channel, the DNS (the HTTPS record), can bootstrap ECH. No HTTPS RR, no ECH.

3 · IP hints: start connecting sooner

Happy Eyeballs v3 already issues the A, AAAA, and HTTPS queries in parallel. The ipv4hint and ipv6hint inside that HTTPS answer give it candidate addresses to start connecting from when the answer arrives before the A/AAAA records, instead of waiting on them. The A/AAAA records still come and supersede the hints; the hints just keep the first connection attempt from stalling on a lookup that has not returned yet. Alt-Svc has no equivalent.

4 · One authoritative source, sane caching

Reachability lives in the DNS with a normal TTL, instead of being smeared across per-origin HTTP-header caches with their max-age dilemma: too long and clients use stale alternatives, too short and they fall back to older protocols more often than they should. The browser was going to do a DNS lookup anyway; this just makes that lookup carry the answer.

from a real browser

Firefox Nightly Measured by Firefox itself, via Mozilla's public GLAM telemetry.

A browser can learn that a server speaks HTTP/3 in two ways: from the Alt-Svc HTTP response header (seen only after it has already connected), or from an HTTPS DNS record (seen before connecting). So every connection falls into one of four groups:

• Neither: HTTP/3 was not advertised at all.
• Alt-Svc only: advertised, but only in the header, so the first connection could not use it.
• HTTPS record only: advertised in DNS, so the first connection could go straight to HTTP/3.
• Both: advertised in DNS and the header.

HTTP/3 discovery, by the numbers

Share of measured connections, Firefox Nightly. The four groups cover every connection, so they add up to 100%. The two right-hand groups had a usable HTTPS record; Alt-Svc only is the gap a record would close.

How it is developing over time

Each bar is one Nightly build, split into the four groups (100%). Firefox Nightly only.

publish one (it's one line)

A ServiceMode HTTPS record advertising h3, with address hints:

; zone file (BIND-style)
example.com.  3600  IN  HTTPS 1 . alpn="h3,h2" ipv4hint=203.0.113.10 ipv6hint=2001:db8::10

Reading it left to right:

• example.com. the name you publish it under; the trailing dot makes it fully qualified.
• 3600 the TTL: how many seconds a resolver may cache the record.
• IN the DNS class (Internet), as on every web record.
• HTTPS the record type (RFC 9460).
• 1 the priority. 1 or higher is ServiceMode (this record carries the parameters); 0 is AliasMode, which just points at another target.
• . the target host. . means the owner name itself, here example.com.
• alpn="h3,h2" the protocols the server speaks, best first: h3 is HTTP/3, h2 is HTTP/2.
• ipv4hint / ipv6hint addresses the client can start connecting to right away, alongside its A/AAAA lookups.

Most managed DNS providers (Cloudflare, Route 53, and others) expose an HTTPS record type directly. Verify yours with the checker.

what HTTPS records carry in the wild

Firefox Nightly Of the connections where Firefox saw an HTTPS record, the share whose record carried each feature.

Source: Firefox Nightly, via GLAM. Per-connection estimate reconstructed from GLAM's histograms, so approximate.

faq

Does my CDN publish this automatically?

Some do. Cloudflare, for one, serves an HTTPS record with alpn="h3" automatically for proxied zones. Others leave it to you. The quickest way to find out is to check your domain above.

Will an HTTPS record break older clients?

No. A client that doesn't understand HTTPS records just ignores them and falls back to ordinary A/AAAA lookups (and your Alt-Svc header, if you still send it). Publishing one is strictly additive.

What about repeat visits?

Even better: once a client has spoken HTTP/3 with you, a return visit can resume the QUIC connection in 0-RTT, putting the first request on the wire with no handshake round trip at all. And the HTTPS record itself is cached for its TTL like any DNS answer, so repeat visits usually skip the lookup too.

Which browsers use the HTTPS record, and do they need DoH?

All the major engines support it, on by default, and read the record whether or not the visitor has DNS-over-HTTPS enabled: Safari uses the operating-system resolver, Chrome its own built-in resolver (over DoH or plain DNS), and Firefox either.

Should I drop the Alt-Svc header?

No. Keep sending it as a fallback for anything that did not get the HTTPS record: older clients, and resolvers or networks that do not deliver it. With the record in place, browsers that do read it learn about HTTP/3 from DNS instead, and no longer spend a round trip discovering it.