savearoundtrip: publish an HTTPS DNS record, skip a round trip

⏱️">

Advertise HTTP/3 support in an HTTPS DNS record, not just an Alt-Svc<br>header, and browsers use HTTP/3 (QUIC) on the first connection.

A browser can discover a site's HTTP/3 support two ways: either by first connecting<br>over HTTP/1 or HTTP/2 and reading its Alt-Svc HTTP header, or right<br>away from an HTTPS DNS record lookup. Only with the HTTPS DNS record<br>can the browser use HTTP/3 on the first connection, saving a round trip using QUIC.

of connections in Firefox Nightly reach HTTP/3 only on a later<br>connection: the site advertised HTTP/3 only in an Alt-Svc HTTP<br>header, not in DNS, though it could have published both. A published<br>HTTPS record would have saved each one a round trip on the first<br>connection.

loading from GLAM...

check a domain

look up

try:<br>savearoundtrip.com<br>cloudflare.com<br>blog.mozilla.org<br>github.com<br>example.com

This live checker needs JavaScript. You can run the<br>same query yourself: dig +short HTTPS example.com (or<br>kdig / dog).

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

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

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

what a round trip costs

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

the wasted round trip

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

HTTP/3 advertised only via the Alt-Svc HTTP header

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

HTTP/3 only on the second connection.

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

HTTP/3 advertised in an HTTPS DNS record

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

HTTP/3 right away, on the first connection.

why the HTTPS record is strictly better

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

1 · HTTP/3 discovery before the first byte

The alpn SvcParam lists the<br>ALPN protocol IDs the<br>endpoint speaks, e.g. h3 (HTTP/3) and<br>h2. Because it arrives during name resolution, the client<br>can pick QUIC for its very first connection instead of discovering<br>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<br>public keys (RFC 9849).<br>ECH encrypts the TLS ClientHello, including the SNI server name, so a<br>network observer can't see which site you're visiting. This is a<br>chicken-and-egg problem an HTTP header can't solve: you need the public<br>key before you send the first ClientHello, which is exactly when no<br>connection exists yet. Only an out-of-band channel, the DNS (the<br>HTTPS record), can bootstrap ECH. No HTTPS RR, no ECH.

3 · IP hints: start connecting sooner

Happy<br>Eyeballs v3 already issues the A, AAAA, and HTTPS queries in parallel.<br>The ipv4hint and ipv6hint inside that HTTPS answer<br>give it candidate addresses to start connecting from when the answer<br>arrives before the A/AAAA records, instead of waiting on them. The A/AAAA<br>records still come and supersede the hints; the hints just keep the first<br>connection attempt...