Every time you type www.google.com and hit enter, your computer doesn't actually know where Google lives on the internet — it has to ask for directions. That's DNS: the internet's phonebook, translating human-readable names into machine-readable IP addresses. Let's follow a single DNS query from the moment you press enter to the moment your browser connects.

Why we need DNS

Imagine memorizing 142.250.185.46 instead of typing google.com. IP addresses change, servers move, but domain names stay constant and memorable. DNS is the bridge between human memory and computer networking.

The journey of a DNS query

1. Browser cache

Before asking anyone, your browser checks its own DNS cache. Each entry has a TTL (Time To Live). If there's a valid, non-expired entry, the journey ends here — microseconds. Let's assume it's a miss.

2. OS cache

Your browser asks the OS, which keeps its own cache shared across all apps. On Windows you can view it with ipconfig /displaydns. Still a miss in our scenario.

3. Hosts file

The OS checks the hosts file (/etc/hosts on Unix, C:\Windows\System32\drivers\etc\hosts on Windows). It's a manual override — admins use it for testing, and you can block domains by pointing them at 127.0.0.1. No entry for public sites, so we move on.

4. The recursive resolver

Now we leave your computer. The OS sends the query to a recursive resolver — usually your ISP's, or a public one like Google's 8.8.8.8 or Cloudflare's 1.1.1.1. Think of it as a librarian: it doesn't know the answer offhand, but it knows how to find it. The query carries the domain name, the record type (usually A for IPv4), and your return address.

5. The resolver's cache

The resolver serves thousands or millions of users, so popular domains are almost always cached. If www.example.com is cached and fresh, you get an answer in 10–50 ms. If not, it recursively walks the DNS hierarchy on your behalf.

6. Root servers

At the top of the DNS tree are the root servers — 13 sets (A–M), each actually a globally distributed cluster via anycast. The root doesn't know where your domain is, but it knows who runs .com, and returns a referral to the .com TLD servers.

7. TLD servers

The resolver asks the .com TLD servers. They maintain the registry of which authoritative nameservers handle each .com domain, and return another referral:

example.com is managed by:
ns1.examplehost.com (198.51.100.1)
ns2.examplehost.com (198.51.100.2)

8. Authoritative nameservers

This is the source of truth. The resolver asks the authoritative nameserver, which looks up the record in its zone file:

www.example.com.    3600    IN    A    93.184.216.34

• 3600 — TTL in seconds (how long to cache)
• IN — Internet class
• A — record type (IPv4; AAAA for IPv6)
• 93.184.216.34 — the IP

9–10. The return journey and local caching

The resolver caches the answer (respecting the TTL) and returns it. Your OS caches it, passes it to the browser, which also caches it. Next time, it's instant.

11. Making the connection

With the IP in hand, the browser opens a TCP connection (port 80 for HTTP, 443 for HTTPS), does the handshake (+ TLS for HTTPS), sends an HTTP GET, and renders the page. The whole DNS process on a cold query is typically 20–120 ms; cached, under 10 ms.

The flow: Browser → OS Cache → Recursive Resolver → Root → TLD → Authoritative NS → back to Browser.

DNS record types beyond A

• A — domain → IPv4
• AAAA — domain → IPv6
• CNAME — alias from one domain to another
• MX — mail servers (with priorities for redundancy)
• TXT — arbitrary text; used for domain verification, SPF, DKIM
• NS — which servers are authoritative
• SOA — administrative info for the zone
• PTR — reverse of an A record (IP → name), important for mail server legitimacy

The importance of TTL

Every record has a TTL set by the owner — a balance:

• Short TTL (60–300s): changes propagate fast, but more query load on your nameservers.
• Long TTL (3600–86400s): big reduction in query load and better performance, but changes can take up to a day to propagate.

Common practice: long TTLs for stable infrastructure, but lower it to 5–10 minutes before a planned change, then raise it back afterward.

How fast is DNS, really?

• Browser cache hit: <1 ms
• OS cache hit: 1–5 ms
• Resolver cache hit: 10–30 ms
• Full recursive query (cold): 20–120 ms
• DNS over HTTPS: +10–50 ms for encryption

For popular sites, resolver cache hit rates approach 95%, so root servers handle less than 1% of all queries. That's how DNS scales to trillions of queries a day.

Why it's so fast: anycast

Multiple servers worldwide share the same IP. Query 8.8.8.8 and you're routed to the nearest one — Tokyo users hit Tokyo, London users hit London. You're not crossing oceans; you're connecting to a server nearby.

DNS and CDNs

CDNs (Cloudflare, Akamai, CloudFront) use GeoDNS: the authoritative nameserver examines where the query comes from and returns the optimal IP for that location. Some go further with DNS-based load balancing based on server health or load.

The invisible infrastructure

DNS is one of the internet's most critical yet invisible services. Every click begins with a DNS query. When it works, it's invisible; when it fails, the internet seems broken. The next time you press enter, appreciate the journey — in milliseconds, your request cascades through caches, crosses continents, and returns with an answer.

Originally published on srinun.in. I write about DevOps, AWS, and Kubernetes — connect with me on LinkedIn.