How DNS Works: A Practical Guide for DevOps and Developers

Source: Dev.to

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. 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. 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. 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. 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. 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. 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. 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. 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)

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 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. 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. 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 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. 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. 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. 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. 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.