FUNDAMENTALS · MECHANISM WALKTHROUGH

DNS to First Encrypted Byte
The Deep Dive

a zoomed-in version of two specific stages from the broader "URL to Page Load" walkthrough — the DNS resolver hierarchy and the TLS handshake, message by message, in the depth an interviewer digging on either topic specifically would expect.

CACHE CHECKS→ RECURSIVE RESOLVER→ ROOT → TLD → AUTHORITATIVE→ IP RETURNED→ TCP HANDSHAKE→ CLIENTHELLO / SERVERHELLO→ CERT VALIDATION→ KEY EXCHANGE→ FIRST ENCRYPTED BYTE

01 The Full Sequence — Worked Example

Cache Checks — Three Layers Before Any Query Leaves the Machine

The browser checks its own DNS cache; if empty, the OS checks its resolver cache; if still empty, the OS checks the local hosts file. Only if all three miss does an actual DNS query leave the machine at all — most repeat visits to a site never get past this step.

Cache

Query Sent to the Recursive Resolver

A recursive query (UDP/53) goes to the configured resolver — an ISP resolver or a public one like 8.8.8.8. "Recursive" means the client is asking the resolver to do all the remaining work and hand back a final answer, rather than following referrals itself.

Recursive

The Resolver's Own Cache

The recursive resolver checks its own cache first. If it already has a valid (non-expired) answer for this domain from a prior lookup by any client, it returns that immediately — no further queries needed.

Resolver Cache

Iterative Resolution — Root → TLD → Authoritative

On a full cache miss, the resolver performs iterative queries, each one a referral to the next level: it asks a root server ("who handles .com?"), gets referred to a TLD server, asks that ("who's authoritative for example.com?"), gets referred to the domain's authoritative name server, and finally asks that server directly for the actual A/AAAA record.

Iterative

Checkpoint — IP Obtained, Cached at Every Layer

The resolved IP (93.184.216.34) is returned to the client, and cached with its own TTL at the resolver, and then again at the OS and browser layers on the client side. Multi-layer caching — not just one cache — is exactly why this entire sequence is skipped on subsequent visits until the relevant TTLs expire.

Checkpoint

TCP Handshake Toward That IP

SYN, SYN-ACK, ACK toward 93.184.216.34:443 — the standard three-way handshake. (Covered in full depth, including what happens if the third packet never arrives, on its own dedicated sheet.)

TCP

TLS ClientHello

The client sends its supported TLS versions, cipher suites, and a key share for the key exchange — plus, critically, the SNI (Server Name Indication) field stating which hostname it's trying to reach. SNI exists because a single IP often hosts many different HTTPS domains; without it, the server wouldn't know which certificate to present.

ClientHello

ServerHello and Certificate

The server responds with its chosen cipher suite, its key share, and its certificate chain. In TLS 1.3, the server can start encrypting the rest of the handshake immediately after this point — in TLS 1.2 several more round trips in plaintext were required first, which is the core reason 1.3 is faster.

ServerHello

Certificate Chain Validation

The client walks the presented certificate chain up to a trusted root CA already in its trust store, checks the certificate's validity dates, confirms the hostname matches the certificate's SAN, and checks revocation status — ideally via OCSP stapling, where the server includes a pre-fetched, signed revocation proof directly in the handshake, avoiding a separate round trip to the CA.

Cert Validation

Key Exchange Completes

Using ephemeral Diffie-Hellman, both sides independently derive the same symmetric session key from the exchanged key shares — the key itself is never transmitted, only the public values needed to compute it.

Key Exchange

Finished Messages and the First Encrypted Byte

Both sides send a "Finished" message — a MAC computed over the entire handshake transcript — proving neither the earlier ClientHello/ServerHello nor anything in between was tampered with in transit. From this point on, every byte is encrypted under the derived session key. The very first TLS application-data record the server sends — carrying the beginning of the HTTP response — is, literally, the "first encrypted byte" this question asks about.

First Byte

02 How to Explain This in an Interview

Frame this as a zoom-in, not a repeat. If you've already covered the broader "URL to Page Load" flow, say so explicitly — "this is the detailed version of steps 2 and 4-5 from that walkthrough" shows you understand these as related, nested mechanisms rather than isolated trivia.
Name recursive vs. iterative precisely. The client-to-resolver query is recursive; the resolver's own queries to root/TLD/authoritative are iterative. Mixing these up is a common and easily-caught mistake.
Bring up SNI unprompted when discussing the ClientHello. It's the detail that explains how shared-IP hosting works at all with HTTPS, and it's a frequent, natural follow-up.
Say why TLS 1.3 is faster, not just that it is. "1-RTT because key exchange parameters ride along in the first ClientHello instead of being negotiated afterward" is a precise, confident answer.
Mention OCSP stapling if certificate validation comes up. It shows awareness of a real performance/privacy optimization, not just "the browser checks the cert."

03 Follow-Up / Gotcha Questions

Q What's the actual difference between a recursive and an iterative DNS query?

A In a recursive query, the receiver does all the work and returns a final answer — that's what a client asks of its configured resolver. In an iterative query, the receiver can respond with "I don't know, but ask this other server" — that's how the resolver interacts with root, TLD, and authoritative servers, following referrals itself.

Q What is SNI, and why does it matter for shared hosting?

A Server Name Indication is a field in the ClientHello stating which hostname the client is trying to reach, sent before the TLS session is encrypted. Without it, a server hosting many HTTPS sites on one IP would have no way to know which certificate to present during the handshake — SNI is what makes name-based HTTPS virtual hosting possible at all.

Q What's OCSP stapling and why is it better than a standalone OCSP check?

A Standalone OCSP requires the client to make its own separate network call to the CA's OCSP responder during the handshake to check revocation status — adding latency and leaking browsing activity to the CA. OCSP stapling has the server periodically fetch a signed, time-stamped revocation proof itself and "staple" it directly into the handshake, so the client validates it locally with no extra round trip.

Q Why exactly is TLS 1.3's handshake faster than TLS 1.2's?

A TLS 1.2 negotiates the cipher suite and key exchange across multiple round trips before any application data can flow — commonly described as 2-RTT. TLS 1.3 has the client send its key share speculatively in the very first ClientHello, letting the server respond with everything needed to finish the handshake and start encrypting immediately after — reducing it to 1-RTT (or 0-RTT for resumed sessions).

Q What happens if the certificate chain fails to validate?

A The browser aborts the handshake and shows a hard interstitial warning rather than silently proceeding — whether the failure is an untrusted root, an expired certificate, a hostname mismatch, or a revoked certificate, TLS treats validation failure as a hard stop by design, since a broken chain of trust is exactly the scenario TLS exists to prevent.

Q Is the DNS query itself encrypted by default?

A Classic DNS over UDP/53 is plaintext by default — anyone on the path can see which domains are being resolved. DoH (DNS over HTTPS) and DoT (DNS over TLS) encrypt this specific query, and are increasingly enabled by default in modern browsers/OSes, but they're a distinct, separate protocol layer from the TLS handshake used for the actual website connection.

04 Quick-Fire Glossary

Term	Meaning
Recursive Query	A query where the receiver is asked to fully resolve and return a final answer
Iterative Query	A query where the receiver may respond with a referral to another server instead of a final answer
Root / TLD / Authoritative	The three-tier hierarchy a recursive resolver walks to resolve a name it doesn't have cached
TTL	How long a DNS record may be cached before it must be re-queried
SNI	Server Name Indication — the hostname sent in cleartext in the ClientHello, enabling shared-IP HTTPS
Cipher Suite	The agreed combination of key exchange, encryption, and MAC algorithms for the TLS session
Certificate Chain	The path from a server's certificate up to a trusted root CA, validated at handshake time
OCSP Stapling	The server pre-fetching and including its own certificate's revocation proof in the handshake
Ephemeral Diffie-Hellman	A key exchange producing a unique session key per connection, supporting forward secrecy
DoH / DoT	DNS over HTTPS / DNS over TLS — encrypting the DNS query itself, separate from the TLS handshake to the site