DNS, HTTP, and the Move to QUIC

Every connection in the previous lessons started from an IP address. Nothing in a browser does. It starts from a name, and turning that name into an address is a distributed database query that happens before the first packet of your actual request.

The Domain Name System, defined in RFC 1034 and RFC 1035, is a hierarchical delegation tree read right to left. In www.example.com the trailing empty label is the root, then com, then example, then www. Each level tells you nothing except which servers know about the level below.

That design choice is the whole point. No single machine holds the mapping. The root knows only which servers run com. The com servers know only which nameservers a domain delegated to. Only those final nameservers hold the actual address record.

The cost is that a cold lookup can take several round trips before your connection even begins. The benefit is that a domain owner changes their records without asking anyone.

Three distinct roles get lumped together as "DNS", and confusing them makes every debugging session harder.

• The stub resolver lives in your operating system. It is deliberately dumb: it sends one query to a configured server and waits for a final answer. It cannot follow delegations.
• The recursive resolver does the work. Your ISP runs one, and so do public services like 8.8.8.8 and 1.1.1.1. It walks the tree, caches everything it learns, and returns a complete answer.
• The authoritative server holds the actual zone data for a domain and answers only for the names it owns. It never chases referrals on your behalf.

A reply carries an authority flag that tells you which kind you got. This is why a record can be correct at the registrar, correct at the authoritative server, and still wrong for a user: their recursive resolver is serving a cached copy, and no amount of fixing the origin changes that until the cache expires.

You can perform a recursive resolver's job manually, one referral at a time. Start by asking a root server which nameservers run a top-level domain:

> nslookup -type=NS com. a.root-servers.net
Server:  a.root-servers.net
Address: 198.41.0.4

com     nameserver = l.gtld-servers.net
com     nameserver = j.gtld-servers.net
com     nameserver = h.gtld-servers.net
com     nameserver = d.gtld-servers.net

The root did not answer the question you care about. It handed back a referral. You would then ask a gtld-server which nameservers a domain delegated to, and finally ask those for the record itself:

> nslookup -type=NS anylearn.cc
anylearn.cc     nameserver = arch.ns.cloudflare.com
anylearn.cc     nameserver = jasmine.ns.cloudflare.com

Notice that the referral includes glue records, the IP addresses of those nameservers. Without glue you could not resolve arch.ns.cloudflare.com without first resolving arch.ns.cloudflare.com, and the whole system would deadlock on its own bootstrap.

With an empty cache, a single name costs the recursive resolver three referrals before it can answer.

Nobody would tolerate three referrals per lookup, so every record carries a time to live and resolvers cache aggressively. Query a name twice and watch the number fall:

> nslookup -type=A -debug example.com 8.8.8.8
    ttl = 206 (3 mins 26 secs)
    internet address = 104.20.23.154
    ttl = 206 (3 mins 26 secs)
    internet address = 172.66.147.243

That 206 is the remainder of the resolver's countdown, not the record's configured value. When it hits zero the resolver goes back to the authoritative server.

Failures are cached too. RFC 2308 defines negative caching: the TTL for a nonexistent name comes from the minimum of the zone's SOA MINIMUM field and the SOA record's own TTL, and the RFC advises resolvers to cap negative caching at one to three hours because longer values proved harmful in practice.

The operational consequence is a rule worth internalising. TTL is your rollback speed. If a record has a 24-hour TTL and you point it at a broken server, you own that mistake for 24 hours. Lower the TTL a day before a migration, not during it.

The root of the tree is famously limited to 13 names, from a.root-servers.net to m.root-servers.net. The constraint was a packet, not a policy: classic DNS over UDP capped a message at 512 bytes, and 13 nameserver records with their IPv4 glue was the most that fit without fragmenting.

That number is now almost decorative. Those 13 names are announced by anycast, meaning many physically separate machines announce the identical IP prefix from different locations, and BGP routes each query to whichever instance is nearest in routing terms. The Root Server Technical Operations Association reported 2,001 operational instances on 20 July 2026, run by 12 independent organisations.

Anycast is the same trick that keeps 1.1.1.1 and 8.8.8.8 fast worldwide, and it works because DNS queries are single-packet request and reply exchanges over UDP. There is no connection state to lose if routing shifts a query to a different instance mid-flight, which is exactly why anycast is straightforward for DNS and considerably harder for long-lived TCP.

With an address in hand and a TCP connection open, HTTP/1.1 as specified in RFC 9112 sends a text request and reads a text response. One at a time.

HTTP/1.1 does allow pipelining: send several requests without waiting. The catch is that responses must come back in request order. A slow first response blocks every response queued behind it, even if they are all ready. That is head-of-line blocking at the application layer, and it is why no major browser ever shipped pipelining on by default; Firefox removed the support entirely.

With pipelining unusable, the workaround was parallel connections, typically six per origin. Each one pays its own handshake and its own slow start, and six connections competing for one bottleneck also confuses congestion control.

That limit then shaped a decade of web practice. Domain sharding split assets across img1.example.com and img2.example.com to buy six more connections each. Sprite sheets bundled dozens of icons into one image. Concatenated bundles turned many small files into one big file. All of it was working around a protocol constraint, and all of it became counterproductive the moment that constraint was lifted.

HTTP/2, specified in RFC 9113, keeps HTTP semantics identical and rewrites the wire format. Three changes carry the weight.

First, framing is binary. A message becomes a sequence of typed frames such as HEADERS and DATA, each tagged with a stream identifier. Parsing is unambiguous and cheap.

Second, streams are multiplexed. Many concurrent requests share one TCP connection, their frames interleaved, and responses arrive in whatever order they are ready. The application-layer ordering trap is gone, and with it the reason for domain sharding and sprite sheets.

Third, headers are compressed with HPACK, which maintains a shared table of previously sent header fields. In HTTP/1.1 every request repeats the same several hundred bytes of cookies and user agent. HPACK reduces the repeat to a table index.

One connection also means one handshake, one TLS negotiation, and one congestion window that stays warm instead of six that keep restarting. That last point matters more than the header savings on most real pages.

Multiplexing solved head-of-line blocking in HTTP. It could not solve it in TCP, because TCP has no idea the streams exist.

TCP delivers one ordered byte stream. When a segment is lost, the kernel holds every later byte in its receive buffer until the retransmission arrives, because handing them up would violate the ordering guarantee. Those held bytes may belong to twenty unrelated streams that are perfectly complete.

RFC 9114 states it directly: "because the parallel nature of HTTP/2's multiplexing is not visible to TCP's loss recovery mechanisms, a lost or reordered packet causes all active transactions to experience a stall regardless of whether that transaction was impacted by the lost packet."

The irony is exact. HTTP/1.1 with six connections had six independent TCP streams, so one loss stalled roughly one sixth of the page. HTTP/2 with one connection concentrated everything, so one loss stalls all of it. On a clean network HTTP/2 wins comfortably; on a lossy mobile link the comparison narrows and can invert.

Fixing this requires a transport that knows about streams. TCP cannot be changed, because middleboxes everywhere would reject anything unfamiliar.

QUIC, specified in RFC 9000, is a transport built on UDP. UDP is not the point; it is the delivery vehicle, chosen because it is the only thing every network already forwards and no middlebox tries to interpret. Everything TCP does is reimplemented above it, in userspace, where it can actually be changed.

The defining property is that streams are a transport concept. RFC 9000 describes streams that "can be created by either endpoint, can concurrently send data interleaved with other streams, and can be canceled." QUIC tracks loss per packet and delivery order per stream, so a lost packet blocks only the streams whose bytes were in it. Everything else is delivered immediately. That is the HTTP/2 problem removed at the layer where it actually lives.

Two more consequences follow. TLS 1.3 is integrated into the handshake rather than layered on top, so the cryptographic setup and the transport setup share round trips. And a connection is identified by a connection ID rather than by the four-tuple of addresses and ports, so it survives a change of network path. Walk out of Wi-Fi onto cellular and your address changes, but the connection ID does not, and the session continues.

HTTP/3, published as RFC 9114 in June 2022, is HTTP/2's model mapped onto QUIC streams. Same methods, same status codes, same header semantics. Each request and response pair gets its own QUIC stream, and header compression moves from HPACK to QPACK, which is redesigned so that out-of-order stream delivery cannot corrupt the shared compression table.

The headline feature is 0-RTT resumption. A client that has connected before can encrypt a request with cached parameters and send it in its very first packet, so the request is already at the server when the handshake completes.

The bargain is spelled out in the specification. 0-RTT data has no replay protection: an attacker who captures that first flight can send it again later, and the server cannot tell the difference. So 0-RTT is only safe for idempotent requests, and a server that receives something it will not process early responds with 425 Too Early to force a full handshake and a retry.

Gotcha: "idempotent" here is a property of what the request does, not of its method. A GET that increments a counter is not safe to replay just because it is a GET.

All three versions are in production simultaneously, and none is universally best.

Cloudflare's 2025 Radar Year in Review reported the split across its own traffic as 50 percent HTTP/2, 29 percent HTTP/1.x, and 21 percent HTTP/3, with all three roughly flat over the year.

HTTP/3 is not a free upgrade either. Zhang and colleagues, in "QUIC is not Quick Enough over Fast Internet" at the ACM Web Conference 2024, measured up to a 45.2 percent reduction in data rate against TCP with HTTP/2 on high-bandwidth paths, and traced it to receiver-side processing cost rather than to the protocol design: too many small packets and acknowledgements handled in userspace. The gap widened as bandwidth rose.

The general lesson holds beyond QUIC. Moving a protocol out of the kernel buys evolvability and costs CPU per packet, and which side wins depends on the network you are actually on.