DNS, HTTP versions and TLS

Why it matters

Explaining what happens when you load a URL exercises every layer at once. In real systems the same pieces cause incidents: a DNS change that takes hours to take effect because of a long TTL, an expired certificate, a client that opens a new TLS connection per request and burns CPU and round trips, or a proxy that silently downgrades HTTP/2 to HTTP/1.1.

Core ideas

DNS resolution. An application asks the stub resolver in the OS, which asks a recursive resolver (ISP, corporate or public). With an empty cache, the recursive resolver walks the hierarchy: a root server refers it to the top-level-domain servers, which refer it to the domain's authoritative servers, which return the records (A and AAAA for addresses, CNAME for aliases, NS for delegation, plus MX, TXT and others). Every record carries a TTL and is cached at each level, and negative answers such as NXDOMAIN are cached too. Consequences: lowering a TTL helps only after the old, longer TTL has expired everywhere; some clients and runtimes cache longer than the TTL; DNS-based failover is never instant. DNS mostly runs over UDP port 53 and falls back to TCP for large answers; DNS over TLS or HTTPS changes who can observe the queries.

HTTP versions. Semantics (methods, status codes, headers, caching rules) are shared across versions; the wire format differs. HTTP/1.1 sends text messages one at a time per connection. Persistent connections (keep-alive) avoid a new handshake per request, but a slow response blocks the next one on that connection, so browsers open several connections per origin. HTTP/2 multiplexes many concurrent streams over one TCP connection with binary framing and header compression; that removes blocking between requests at the HTTP layer, but one lost TCP segment still stalls every stream. HTTP/3 maps HTTP onto QUIC over UDP, where streams are independent in the transport and the transport and TLS handshakes are combined.

TLS 1.3. The client sends a ClientHello with supported versions, cipher suites and a key share. The server answers with a ServerHello and its key share, and everything after that is encrypted: its certificate, a CertificateVerify signature proving it holds the private key, and Finished. The client validates the certificate chain up to a trusted root and checks that the certificate covers the requested name. A full handshake adds one round trip on top of TCP's. Resumption with a pre-shared key skips certificate work, and 0-RTT lets the client send data in its first flight, at the price of possible replay, so only idempotent requests should use it. TLS 1.3 removed static RSA key exchange, so every full handshake provides forward secrecy.

Connection reuse. A new HTTPS connection over TCP costs a DNS lookup, one round trip for TCP and one for TLS 1.3 before the request can leave; on a path with a 100 ms RTT, that is about 200 ms plus DNS time before the first request byte is even sent. Connection pools and keep-alive amortize this, and HTTP/2 lets one connection carry many concurrent requests. Pool sizes, idle timeouts and load-balancer behavior then determine tail latency and correctness.

Common misconceptions

• "DNS changes propagate." Nothing is pushed: caches expire on their own TTLs, and some clients ignore TTLs.
• "HTTP/2 eliminates head-of-line blocking." It removes blocking between requests at the HTTP layer; TCP loss still blocks every stream on the connection.
• "TLS hides which site I am visiting." The server name in the ClientHello is visible unless Encrypted Client Hello is used, and DNS queries may reveal it too.
• "0-RTT is a free speedup." Early data can be replayed by an attacker, so servers restrict it to idempotent requests or add anti-replay measures.
• "HTTP/3 is HTTP/2 over UDP." It relies on QUIC for streams, loss recovery, encryption and connection migration, and uses its own header compression (QPACK).

How to approach it

Narrate a cold HTTPS request with a round-trip budget, then explain which round trips disappear with caching, keep-alive, TLS resumption and HTTP/3. Use dig +trace and curl -v to see real exchanges. Mid and senior questions cover DNS-based failover and TTL tradeoffs, certificate rotation, connection pooling under load, and when HTTP/2 multiplexing helps or hurts.