HTTPS Records in DNS: How HTTP/3 Discovery Works

HTTP/3 carries HTTP over QUIC, which uses UDP. A client can try QUIC directly without a prior advertisement. Success still depends on the endpoint and network path. Failure may be immediate or become apparent only when a time limit expires.

Two information sources help with selection: Alt-Svc names an alternative service in an HTTP response; an HTTPS DNS record can provide connection parameters before the first HTTP request. Both advertise possibilities, without guaranteeing a reachable or faster connection.

Alt-Svc can help during the same page view

Alt-Svc: h3=":443"; ma=86400 advertises an equivalent HTTP/3 service on UDP port 443 at the same host. ma gives the freshness lifetime for new connection attempts in seconds. Use of the alternative is optional; certificate validation for the original host still applies.

Without a previous cache entry or another information source, the header is often first received over HTTP/1.1 or HTTP/2. After reading it, a supporting client can establish an additional QUIC connection. This does not require another website visit: further resources on the same page may already benefit. The original TCP connection need not close first.

What an HTTPS record adds

The HTTPS DNS type has number 65 and belongs to the SVCB framework. For an ordinary HTTPS URL on port 443, the lookup uses the hostname. A ServiceMode record describes a potential endpoint: the server name, port and supported application protocols such as HTTP/3. These protocols are identified by ALPN names. AliasMode instead points to another name whose records need further resolution.

alpn="h3,h2" advertises HTTP/3 and HTTP/2. A compatible client can therefore try the first HTTP request over QUIC. Selection, parallel connection attempts, cache state and network conditions determine the actual sequence. A DNS record does not enable HTTP/3 on the server.

ipv4hint and ipv6hint supply address hints for an early connection attempt. Available A/AAAA answers take precedence; otherwise the corresponding lookups should still take place. Hints therefore do not generally replace address resolution.

The ech parameter can carry an ECH configuration list containing a public key and additional information. With supporting clients and servers, ECH protects the inner TLS server name and other fields. A DNS advertisement does not prove successful ECH use. Plaintext DNS queries or visible destination addresses can still reveal information, and ECH configuration can also be supplied through other mechanisms.

Historical results from 20 domains

The saved tool results from 5 September 2026 were reanalysed during this revision. The following table describes that historical run, not a current provider measurement or representative market share.

The two domains advertising h3 in HTTPS records also had a corresponding Alt-Svc header. This was not true of every HTTPS record: the third listed only h2 and had no Alt-Svc header. Seven versus two gives a factor of 3.5 for observed HTTP/3 advertisements; seven versus all three HTTPS records would be only about 2.3.

Five Alt-Svc advertisements had ma values of 86,400 seconds; two used 2,592,000 seconds. No ech parameter was recognised in the processed DNS results. This did not measure negotiated ECH connections, and the DNS processing limitations also matter.

A single error does not establish the cause

The historical h2-only record belonged to stackoverflow.com. Its forced HTTP/3 test ended after 63 milliseconds with “QUIC connection has been shut down”. That does not establish behaviour at every endpoint or the operator’s intention. A valid HTTPS record without h3 is nevertheless not a configuration error in itself.

Two advertised services timed out while other HTTP/3 connections succeeded in the same run. That establishes basic QUIC capability in the measuring setup, but does not explain every failure. For google.com, connection and TLS times were recorded before the request expired without receiving a response. A timeout therefore does not always mean UDP was blocked.

A useful failure report identifies the URL, tested endpoint, IP family, client version, measurement time and location. One failed attempt from one location does not prove a worldwide outage.

TTL and ma govern different caches

The TTL limits how long a DNS answer may normally be reused from a cache. The recursive DNS answers contained TTL values of 20 and 21,474 seconds for the two h3 records. Such values may show remaining cache lifetime. They do not reliably establish the original configured TTL, or prove a deliberate choice of maximum flexibility or minimum resolver load.

A short configured TTL eases changes but may increase query load. Longer values complicate rapid corrections. DNS serve-stale also permits expired data under certain failure conditions. A TTL is therefore not a global switchover guarantee. Likewise, ma is a defined freshness limit for new alternative connections, not merely a suggestion; existing connections need not close at expiry.

Separate checks for advertisement and reachability

The examples use a placeholder. The first request displays response headers from a GET request, followed by a DNS lookup. The last command requires a curl build with HTTP/3 support; curl --version lists available capabilities.

curl --silent --show-error --max-time 15 --dump-header - \
  --output /dev/null https://example.com/
dig +noall +answer HTTPS example.com
kdig -t HTTPS example.com
curl --version
curl --http3-only --silent --show-error --max-time 15 \
  --output /dev/null --write-out 'HTTP %{http_version}\n' \
  https://example.com/

A --http3-only request tests QUIC without TCP fallback. It does not fully demonstrate that a browser discovers the HTTPS record and selects its alternative endpoint. A different target name or port requires a separate check of that exact endpoint. Redirects may also lead to another host and need separate interpretation.

The HTTP/3 and Alt-Svc Discovery Checker combines DNS display, protocol attempts and a further request using an Alt-Svc cache. The inspected implementation does not follow HTTPS aliases, does not apply the DNS target and port to the direct QUIC test, and does not fully handle truncated DNS responses. The second request is a curl test, not a complete browser visit. Individual findings remain useful, but this does not establish comprehensive DNS discovery testing.

The distinction between a forced protocol test and actual client behaviour is also covered in HTTP/3 on a First Visit: How a Client Discovers the Protocol and What Twenty Sites Answered.