DNS flow

Overview

This lesson ties the DNS module together by tracing a complete resolution flow — from typing a name to receiving an IP address — combining resolvers, the hierarchy, records, and caching into one end-to-end picture.

Learning objectives

• Trace a DNS query end to end.
• Show how caching short-circuits the full flow.
• Connect the flow to what happens next (the actual connection).

Core concept

A DNS lookup follows a predictable path, with caching able to cut it short at any step:

1. The application asks the stub resolver for a name.
2. Local caches (application, OS) are checked; a valid cached answer ends the flow immediately.
3. Otherwise the query goes to the recursive resolver, which checks its own cache.
4. On a cache miss, the recursor resolves iteratively: root → TLD → authoritative server.
5. The authoritative server returns the record; the recursor caches it (per its TTL) and replies to the client.
6. The client now has the IP and can open a connection to it.

How it works

Each layer's cache exists precisely to avoid the steps below it. Most everyday lookups never reach the authoritative servers because the answer is already cached at the OS or recursive resolver. Only genuinely new or expired names trigger the full root → TLD → authoritative walk. Once the IP is returned, DNS's job is done and the transport layer (e.g. a TCP handshake) takes over to actually reach the server.

Practical example

You open www.example.com:

1. Browser/OS cache checked — miss (first visit today).
2. Query sent to your recursive resolver — cache miss there too.
3. Recursor asks a root server → referred to .com TLD servers.
4. TLD servers → referred to example.com's authoritative servers.
5. Authoritative server returns the A record (an IP); recursor caches it and replies.
6. Your browser connects to that IP over TCP/443 and loads the page.

A refresh moments later skips straight to a cached answer.

Cybersecurity relevance

The end-to-end flow reveals where security acts and where it can fail: a malicious resolver or poisoned cache can hijack step 3–5; encrypted DNS (DoH/DoT) protects the query in transit; DNSSEC lets a resolver verify the authoritative answer is authentic. Analysts trace this same flow when investigating whether a user was directed to a malicious address and at which point the answer was tampered with.

Common mistakes

• Forgetting caching can end the flow early — most lookups do not reach authoritative servers.
• Treating DNS as the connection — DNS only finds the address; a separate transport connection follows.
• Ignoring where trust is established in the flow when reasoning about attacks and defenses.

Key takeaways

• A full DNS flow runs: application → stub resolver → caches → recursive resolver → root → TLD → authoritative → cached answer → client.
• Caching at each layer short-circuits the flow, so most lookups are answered without a full hierarchy walk.
• DNS only resolves the address; the actual connection (e.g. TCP handshake) happens afterward, and each step of the flow has security implications.

Check your understanding

• At which points in the flow can caching prevent a query from reaching the authoritative servers?
• After DNS returns an IP address, what happens next to actually load the website?