How DNS tells a browser to use HTTP/3
HTTPS records let a website advertise HTTP/3 before the browser opens its first connection to the site.
A traditional DNS lookup gives a browser an IP address and little else. It does not say which versions of HTTP the server speaks, whether another hostname or port would work better, or whether the browser can connect over QUIC instead of TCP. The browser has to open a connection before the web server can tell it any of that.
The HTTPS DNS record gives a website a way to publish those details alongside its addresses. A browser that receives one can learn that HTTP/3 is available before sending its first web request, then open a QUIC connection straight away instead of needing an earlier HTTP connection to discover it.
How the question works
When a browser prepares to open https://example.com, it asks DNS for the usual A and/or AAAA records containing IPv4 and IPv6 addresses. A browser that understands service binding also asks for an HTTPS record for the same name. HTTPS, record type 65, is the HTTP-specific form of the general-purpose SVCB record, type 64; browsers use HTTPS rather than SVCB for http and https URLs. Despite its name, this record does not contain a certificate or a URL. It describes how the service behind that URL can be reached.
The queries can run in parallel, so a website without an HTTPS record need not add another sequential DNS round trip before the browser connects. Where one exists, its answer can name an alternative endpoint, the protocols available there, a different port, and IP address hints that can sometimes let the connection begin without waiting for another lookup.
HTTP versions are identified by short ALPN names. h2 means HTTP/2 over TLS and TCP; h3 means HTTP/3 over QUIC and UDP. Seeing h3 tells the browser that it can attempt QUIC for this site immediately.
What comes back
A simple answer might look like this:
example.com. 300 IN HTTPS 1 . alpn="h2,h3"
The 1 is the endpoint’s priority, with lower numbers normally preferred. Because it is greater than zero, this is a ServiceMode record: the dot means that the endpoint remains on example.com itself, and alpn="h2,h3" advertises HTTP/2 and HTTP/3. HTTPS records also include HTTP/1.1 by default unless no-default-alpn is present. No port is listed, so the browser uses the one from the URL, normally 443.
A priority of 0 switches the record into AliasMode, allowing CNAME-like redirection at the domain apex, where an ordinary CNAME cannot be used. In that mode a domain name identifies the service to follow. A dot is reserved for the opposite meaning: it says that the service is unavailable, though clients may treat that signal as advisory.
A busier service can publish several records with different priorities or point HTTP/3 at a separate server pool. When that target is another name, ipv4hint and ipv6hint addresses can let the browser begin connecting while it resolves the target’s A and AAAA records, avoiding another sequential lookup. They offer little benefit when the target is the original name, since the browser can ask for its address records in parallel and prefers those answers when they are already available. In either case the hints are not replacements for ordinary address records.
Once it has selected an HTTP/3 endpoint, the browser opens a QUIC connection over UDP and offers h3 during the TLS handshake carried by QUIC. The server selects it, and the browser checks the certificate against the name in the original URL—not an alternative hostname supplied by the DNS record. The page then travels over HTTP/3 from its first request.
Where it helps most
The clearest win is a first visit. Without the DNS hint, the usual discovery route begins with an HTTP/2 or HTTP/1.1 connection, after which the server can return an Alt-Svc header advertising HTTP/3. QUIC only gets a chance on a later connection. Moving that advertisement into DNS lets the browser try the preferred transport from the outset.
That is the whole speed-up: the browser learns sooner. On a return visit, cached Alt-Svc information or an existing HTTP/3 connection may already have removed the same delay.
Separate server pools are possible too, although they are probably overkill for most sites. A larger service can advertise one endpoint for HTTP/2 and another for HTTP/3, or publish several alternatives in preference order. The browser can choose a compatible one without first visiting the default server to ask where it should go.
The same machinery reaches beyond transport selection. For a URL that still begins with http, a supporting browser treats a compatible HTTPS record like a redirect to the corresponding HTTPS URL before connecting, avoiding an initial cleartext request. This resembles HSTS, but the signal is cached according to the DNS TTL rather than an HSTS max-age, and a plain, unauthenticated DNS answer can be suppressed or altered. The record can also carry a non-standard port and the configuration needed for ECH, which encrypts the website name normally carried in the TLS Server Name Indication.
Where the shortcut ends
HTTP/3 remains a choice, not a command. Older clients ignore the HTTPS record and continue with ordinary address answers. A supporting browser can fall back to HTTP/2 or HTTP/1.1 when a network blocks or mishandles UDP.
DNS is supplying a route, not granting authority to the server at the end of it. The server still has to negotiate HTTP/3 and present a certificate valid for the website the user asked for, so a forged record cannot make an unrelated server authoritative without also passing that check. An attacker can suppress the HTTP/3 advertisement or block UDP, leaving the browser to use TCP where its fallback policy permits—or causing the connection to fail.
This is one of those optimizations that matters most when nothing is cached. Its useful moment is the narrow one between the browser learning a website’s name and learning how that website prefers to be reached.