How DNS finds a website

First lookup

Beginner

1. You type stackkinetic.com. Your computer asks the librarian: where is that?
2. The librarian starts at the top of the address book.
3. “I don’t know that site, but here’s who handles .com.”
4. The librarian asks the .com section.
5. “Ask this domain’s own servers. Here’s where they are.”
6. The librarian asks the domain’s own servers.
7. “Here’s the address!” And it says how long the answer can be remembered.
8. The librarian hands you the address and remembers it for next time.
9. Now your browser can knock on the right door.
10. The website appears. All those lookups took a blink.

Practitioner

1. The browser asks its configured resolver for the IP address.
2. The resolver asks a root server.
3. The root replies with the .com servers.
4. The resolver asks a .com server.
5. The .com server replies with the domain’s name servers.
6. The resolver queries the authoritative server.
7. The authoritative server returns the IP address and a TTL.
8. The resolver returns the address to the browser.
9. The browser connects to the web server’s IP address.
10. The page loads.

Architect

1. Stub query for the A/AAAA record; local caches missed.
2. Iterative query to a root server (usually skipped thanks to caching).
3. Referral: NS records for the .com TLD.
4. Query to a .com TLD server.
5. Referral: NS records (plus glue) for the domain’s authoritative servers.
6. Query to the authoritative server for the zone.
7. Authoritative A/AAAA answer with TTL; the resolver caches it.
8. Answer returned; resolver and OS caches now hold it until the TTL expires.
9. TCP/TLS handshake to the resolved address; SNI carries the hostname.
10. HTTP response. The DNS chain typically cost tens of milliseconds, once.

Cached answer

Beginner

1. You visit the site again a bit later.
2. The librarian remembers the address, so no need to ask anyone else.
3. Your browser goes straight to the website.
4. The page loads, faster than the first time.

Practitioner

1. The browser asks the resolver again.
2. The resolver answers from its cache.
3. The browser connects to the web server.
4. The page loads.

Architect

1. Stub query; the OS cache may even answer first.
2. Cache hit within TTL: no root, TLD or authoritative traffic.
3. Connection to the cached address.
4. Response. Low TTLs make changes propagate faster but cause more lookups.