Resources

DNS HTTPS Records and Alt-Svc

Two mechanisms advertise HTTP/3 availability to browsers. They solve the same problem from different angles, and understanding both is essential for anyone working with modern HTTP infrastructure or SSE gateways.

This article covers both mechanisms in depth. For the broader context — how Alt-Svc and DNS HTTPS records fit into the full protocol selection flow alongside TLS ALPN, and how browser behavior differs between first and repeat visits — see How do Browser and Website Negotiate Which HTTP Version is Used?

Why Two Mechanisms Exist

The need for a discovery mechanism arises from one simple fact: a browser cannot negotiate HTTP/3 on a TCP connection. Once the transport is TCP, the protocol is H1 or H2. To use H3, the browser must decide to open a QUIC connection instead — and to make that decision, it needs to know in advance that the server speaks QUIC.

Alt-Svc (RFC 7838, 2016) was the first solution. It works by having the server announce H3 availability in an HTTP response header. The browser caches the announcement and uses QUIC on its next connection to that host. The mechanism is simple and requires no changes to DNS infrastructure, but it has a fundamental limitation: the browser must successfully complete an HTTP/1.1 or HTTP/2 request before it can learn about H3. The first connection is always blind. For a site that is H3-only, Alt-Svc alone is not enough — there is no TCP connection to receive the header from.

DNS HTTPS records (RFC 9460, 2023) were designed to close that gap. By embedding protocol information in DNS, they make it available before the browser opens any connection. A browser that receives an HTTPS record with H3 in the ALPN list can attempt QUIC on the very first visit. The mechanism requires DNS infrastructure support — the authoritative server must publish HTTPS records, and the resolver in the path must forward them — but it solves the cold-start problem that Alt-Svc cannot.

The two mechanisms are complementary, not competing. HTTPS records enable first-visit H3. Alt-Svc keeps H3 discoverable even when DNS infrastructure does not support HTTPS records, and it preserves that discovery state across later connections.

Alt-Svc in Detail

The Alt-Svc header is sent by the server in any HTTP response. Its value names one or more alternative endpoints where the same service is available under a different protocol or port.

A typical H3 advertisement:

alt-svc: h3=":443"; ma=86400

The fields:

• h3 — the ALPN protocol identifier for the alternative service
• ":443" — the alternative authority (host and port); an empty host means the same host as the current connection
• ma=86400 — max-age: how long the browser may cache this entry, in seconds (here, 24 hours)

Multiple alternatives can be listed in one header, separated by commas:

alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400

The h3-29 token is a legacy draft identifier still emitted by some servers for compatibility with older clients. Current browsers treat h3 as the standard token.

To withdraw a previously advertised alternative — for example during a maintenance window — the server sends:

alt-svc: clear

This instructs all clients to discard any cached Alt-Svc entries for the host.

The cold-start limitation is the key practical constraint. Alt-Svc requires a successful prior HTTP response. For hosts where the very first connection attempt must succeed over H3 — for example an H3-only server — Alt-Svc cannot help. The browser has no prior response from which to learn. DNS HTTPS records are the only mechanism that addresses this case.

DNS HTTPS Records in Detail

DNS HTTPS records are a specialization of the SVCB (Service Binding) record type defined in RFC 9460. The record type is named HTTPS and carries service parameters for HTTPS endpoints specifically.

A basic record as it appears in a DNS zone file:

sse-testcenter.org.  IN  HTTPS  1  .  alpn="h3,h2,http/1.1"

The fields from left to right:

• sse-testcenter.org. — owner name (the hostname being looked up)
• IN HTTPS — class and record type
• 1 — SvcPriority: lower values are preferred; 0 is a special "alias mode" (see below)
• . — SvcTargetName: a dot means the owner name itself; a different hostname names the service endpoint or alias target, depending on the record mode
• alpn="h3,h2,http/1.1" — service parameter: the ALPN IDs supported by this endpoint

Service parameters beyond alpn:

SvcPriority expresses endpoint preference. The alpn parameter describes which protocol suites are available at that endpoint.

Priority and alias mode:

A SvcPriority of 0 puts the record in "alias mode": the SvcTargetName points to another name where the actual service parameters are found. This allows a canonical name to be shared across multiple endpoints. SvcPriority values of 1 and above are "service mode": the record directly provides parameters. Lower service-mode values are preferred over higher ones.

What a browser does with the record:

When the browser's DNS resolver returns an HTTPS record alongside the A/AAAA answer, the browser inspects the alpn parameter. If h3 appears in the list, the browser may attempt a QUIC connection to the indicated port. If the HTTPS record is absent, or if the resolver strips it, the browser proceeds with a standard TCP connection.

The browser typically issues the HTTPS query in parallel with the A/AAAA query. If the address record arrives before the HTTPS record, the browser may open a TCP connection before H3 availability is known. A later-arriving HTTPS record is then cached for subsequent connections — which is why a first visit to an H3-only host can fail and a reload succeeds.

Checking HTTPS records with dig:

dig HTTPS sse-testcenter.org
dig HTTPS h2-h3.sse-testcenter.org

To query a specific resolver — useful for comparing what a gateway's DNS returns against public DNS:

dig HTTPS sse-testcenter.org @8.8.8.8
dig HTTPS sse-testcenter.org @1.1.1.1

If the HTTPS record is present on public DNS but absent when queried through the gateway's resolver, the gateway is suppressing it.

Side-by-Side Comparison

When each is sufficient alone:

• Alt-Svc alone is sufficient when H3 is offered alongside H2 or H1. The browser can always start on TCP and upgrade on the next visit.
• DNS HTTPS records alone are sufficient for clients that implement them. But not all clients do, and older clients or tools will simply ignore the record.
• Both together is the robust configuration: HTTPS records give first-visit H3 to supporting clients; Alt-Svc ensures repeat-visit H3 even for clients that missed or ignored the DNS record.

Connection Coalescing

DNS HTTPS records introduce a subtlety that is worth understanding separately: connection coalescing.

HTTP/2 and HTTP/3 allow a browser to reuse a single connection for multiple hostnames when the existing connection is considered authoritative for the additional origin. In practice, this usually requires compatible DNS results and a TLS certificate that covers all involved names. This is connection coalescing, and it is an optimization — fewer connections means less handshake overhead.

The complication arises when two hostnames have different HTTPS records. The browser may have already established a connection to one hostname and reuse it for a request to a second hostname, even though the second hostname's HTTPS record would have led to a different protocol choice on a fresh connection.

On SSE TestCenter, for example, a browser that has an H3 connection to sse-testcenter.org may coalesce requests to h2.sse-testcenter.org onto that same H3 connection, even though the h2 host is intended to be H2-only. The IP address matches and the wildcard TLS certificate covers both names.

This is not a misconfiguration — coalescing is specified behavior. But it means that protocol tests run from a single browser session can produce results that reflect the existing connection state rather than the fresh-connection behavior each hostname is designed to test. The Protocol Detection page notes this explicitly and recommends running it from both an H3 and an H2 starting point to minimize coalescing effects.

What Changes with an SSE Gateway

An SSE gateway sits between the browser and the DNS resolver and between the browser and the origin server. It can influence both mechanisms independently.

Effect on Alt-Svc:

A terminating gateway receives the origin's Alt-Svc header on the upstream connection. It may:

• Forward it unchanged to the browser — the browser learns about H3 and will attempt QUIC on the next connection, directly to the gateway if the gateway supports H3, or to the origin if traffic is not intercepted.
• Strip it — the browser never learns about H3 and stays on H2 or H1 indefinitely.
• Rewrite it — the gateway can substitute its own Alt-Svc value, for example advertising its own QUIC endpoint instead of the origin's.

Effect on DNS HTTPS records:

A gateway acting as DNS resolver may:

• Pass HTTPS records through unchanged — browsers receive full protocol information.
• Suppress HTTPS records entirely — browsers lose first-visit H3 discovery; Safari is most affected.
• Return a modified HTTPS record — for example, removing h3 from the alpn list while keeping the record present. This prevents H3 discovery without making the suppression obvious to a simple DNS record check.

What to look for:

Run dig HTTPS for several SSE TestCenter hostnames against both a public resolver and the resolver used by the gateway. Differences in the alpn parameter or the absence of the HTTPS record on the gateway's resolver path are the key findings. Cross-reference with the protocol widget on each hostname page in the Hostname Matrix: if the widget shows H2 where H3 is expected, and the HTTPS record is absent or stripped of h3 on the gateway resolver, the DNS path is the cause.