A lot of network explanations start too late.
The usual mental model goes something like this. The browser resolves a name, opens a TCP connection to port 443, performs a TLS handshake, sends an HTTP request, and the site loads. That model is not entirely wrong, but it is now too small to explain what modern clients and modern edge systems are actually doing.
Before a site loads, more can happen than a bare A or AAAA lookup followed by a generic HTTPS connection. TLS 1.3 still matters. So does ALPN because the client and server need to agree on whether they are speaking HTTP/1.1, HTTP/2 or HTTP/3. QUIC matters because HTTP/3 does not run over TCP at all. HTTPS and SVCB records matter because DNS can now advertise connection information, not just addresses. And ECH matters because some of what used to be visible in the TLS ClientHello can now be encrypted, with the necessary bootstrap information learned via DNS through RFC 9848.
That is a very different picture from simply: resolve, connect, request.
This piece is about that earlier phase. Not the page after it loads and not the HTTP application itself. The focus here is what happens between deciding to visit a site and the moment the first request can actually be sent.
The Old Model Starts Too Late
The older web bootstrap story assumed that DNS gave you an address and that most of the interesting negotiation happened later. If you wanted to know whether a site supported a newer transport or a different HTTP version, you often had to discover that only after making an initial connection. Mechanisms like redirects, HSTS and Alt-Svc all fit that older pattern. The client would connect conservatively first, then learn better ways to connect later.
That works but it leaves useful information stranded behind the very connection that needed it. Cloudflare’s write-up on HTTPS records describes the problem neatly. If HTTP-related parameters are only discovered via HTTP itself, the client has to begin with the safest lowest-common-denominator path and upgrade later.
Modern DNS records change that. RFC 9460 defines the SVCB and HTTPS record types so that clients can learn information needed to make connections to network services including transport-related parameters and, importantly, future extensions such as keys for encrypting the TLS ClientHello. In other words, DNS can now participate in connection bootstrap, not just in name resolution.
That is the first shift to keep in mind. When a client queries DNS for a web origin, it may now be learning more than “what IP address should I dial”.
DNS Can Now Carry Connection Hints
The moment a client resolves a modern HTTPS origin, several things may be available.
There are still the familiar A and AAAA records. Those still matter because ultimately the client needs an address to reach. But there may also be HTTPS records. Those records can advertise alternate service endpoints and associated parameters. In practical terms, that can include things like supported application protocols via ALPN values, along with ECH configuration material when ECH is in use.
That does not mean DNS replaces the handshake. It means DNS can now shape the handshake before it starts.
This distinction matters. An HTTPS record can indicate that a service supports h3 and h2, but the actual application protocol selection still happens through ALPN inside the TLS handshake. The record is advertisement and bootstrap information. It is not the same thing as final negotiation.
That is why RFC 9460 is more interesting than “new DNS record type” makes it sound. It moves some connection setup knowledge into the naming layer. That is already enough to change how the first connection is made.
ALPN Moves Protocol Choice Into the Handshake
ALPN is one of those protocol details that quietly does a lot of work.
The ALPN RFC defines a TLS extension for application-layer protocol negotiation within the TLS handshake. The client sends the list of supported protocols in ClientHello. The server chooses one and returns its selection in the handshake. Critically, this is done without adding an extra round trip.
That sounds small until you notice how many modern behaviours depend on it.
Without ALPN, the client and server would need some other way to agree on whether they are speaking HTTP/1.1, HTTP/2 or HTTP/3. With ALPN, the protocol choice becomes part of the secure bootstrap process itself. That means protocol negotiation is no longer a late-stage application concern. It is part of the handshake path.
ALPN also explains why DNS-advertised protocol hints are only hints. An HTTPS record can tell the client what the origin claims to support. ALPN is where the client and server actually settle the matter.
This is also part of why the old “TLS just encrypts HTTP” story is inadequate. TLS is doing confidentiality and integrity work, yes, but it is also carrying negotiation state that determines what application protocol can even run afterward.
QUIC Changes the Transport Path
At this point the picture becomes even more interesting, because not every HTTPS connection begins with TCP any more.
QUIC is a UDP-based secure transport. RFC 9000 describes it as providing flow-controlled streams, low-latency connection establishment and path migration. RFC 9114 then defines HTTP/3 as HTTP semantics carried over QUIC.
So if the client already knows that an origin supports HTTP/3, the first connection attempt may go straight to QUIC over UDP rather than first opening TCP and discovering HTTP/3 later. RFC 9114 is explicit here: once a client knows that an HTTP/3 server exists at a certain endpoint, it opens a QUIC connection.
That means the transport path can diverge before the site has loaded any content at all.
It is worth being precise here. QUIC is not just “HTTP over UDP”. It incorporates the TLS 1.3 handshake for its security properties. The QUIC transport RFC explicitly says the QUIC handshake incorporates the TLS 1.3 handshake and depends on its cryptographic properties. So the early bootstrap path is now more layered than many simplified explanations allow for:
- DNS may advertise endpoint and protocol information.
- The client may choose QUIC rather than TCP.
- The handshake still uses TLS 1.3 concepts.
- ALPN still determines the application protocol.
- Only then can HTTP semantics actually start.
That is a more involved boot path than most people imagine when they type a URL into a browser.
ECH Changes What the Network Can See
If HTTPS records and QUIC change the connection path, ECH changes the privacy properties of the handshake itself.
Traditionally, the TLS ClientHello exposed quite a lot. In particular, the Server Name Indication, SNI, revealed the intended hostname in plaintext. That meant that even when the application data was encrypted, there was still useful metadata available to networks, intermediaries and observers very early in the connection.
ECH, standardised in RFC 9849, is designed to narrow that exposure. It does this by constructing an inner and outer ClientHello. The sensitive content is carried in the inner one, which is encrypted using configuration the client learned beforehand. That bootstrap mechanism is defined separately in RFC 9848, which uses SVCB or HTTPS DNS records to deliver the ECH configuration.
This is the second major way DNS now participates in the early web path. It is not just helping the client find the server. It may be helping the client encrypt part of the handshake before the first real application data is even sent.
That matters because ECH is not simply “more TLS”. It changes the privacy boundary. RFC 9849 also notes that by encrypting the entire ClientHello, the design supports encrypting the ALPN extension as well. In other words, not just the hostname, but some of the protocol negotiation metadata can move behind the encrypted boundary too.
There are still limits. ECH does not make the destination invisible. IP addresses, packet timing and the existence of the connection remain visible. And the DNS bootstrap itself matters enormously. RFC 9849 is clear that an attacker who can inject or poison DNS can supply fake ECH configurations or strip them from responses. So ECH improves the privacy of the TLS bootstrap, but it also increases the importance of the DNS path that feeds it.
What Actually Happens Before a Site Loads
At a high level, a modern HTTPS connection may look something like this.
- First, the client resolves the origin. That may return A or AAAA records, but it may also return HTTPS records carrying service parameters.
- Second, the client evaluates what those records mean. Are there alternate endpoints. Are there advertised ALPN values. Is ECH configuration present. Is there enough information to attempt HTTP/3 directly.
- Third, the client chooses a transport path. If the endpoint and client policy allow it, that may mean QUIC and HTTP/3. If not, it may mean TCP and a more traditional TLS-protected HTTPS path.
- Fourth, the client performs the cryptographic handshake. With TCP, that is a TLS 1.3 handshake. With QUIC, that is still a TLS 1.3-based handshake integrated into QUIC. ALPN is negotiated here, not in DNS.
- Fifth, if ECH is in use, the client has already used DNS-provided configuration to protect the inner ClientHello before the server processes the handshake in full.
Only after those steps is the browser actually in a position to send the first HTTP request with confidence that it is speaking the right protocol to the right endpoint with the intended privacy properties.
That entire sequence happens before the site meaningfully “loads” in the way users normally think about it.
Why This Matters
The practical lesson is not just that the web is more complicated than it used to be. The more important lesson is that transport, protocol and privacy decisions are now entangled earlier in the stack.
If you are debugging modern connectivity, you cannot stop at “DNS resolved fine”. You may need to know whether HTTPS records were returned, whether they advertised h3, whether the client attempted QUIC, whether ALPN selected the intended protocol, whether ECH configuration was present, and whether the DNS path allowed ECH bootstrap in the first place.
Likewise, if you are designing edge systems, reverse proxies or policy tooling, you cannot treat DNS, TLS and transport as isolated knobs any more. They are increasingly part of one connected bootstrap path.
That is the real takeaway. Before a site loads, the browser may already have made choices about endpoint selection, transport, protocol and handshake privacy, and DNS may have informed all of them.
That is why the old; resolve, connect, request story is no longer enough.