DNS Deep Dive

Every time you type google.com into your browser, something happens before a single byte of the web page loads: your computer has to figure out where google.com actually lives on the internet. That job belongs to the Domain Name System — DNS. It translates human-readable names into the IP addresses that computers use to reach each other. Understanding how that works in depth makes you a much sharper engineer.

The DNS Hierarchy

DNS isn't a single database. It's a tree-shaped, distributed system with three major tiers.

Root servers sit at the very top. There are 13 named root server clusters (labeled A through M), but each "cluster" is actually hundreds of machines spread across the globe using anycast routing. They're operated by organizations like ICANN, Verisign, Cogent, and NASA. The root servers don't know where google.com is — but they know which servers are responsible for .com.

TLD servers (Top-Level Domain) are the next tier down. When you ask about a .com domain, the root server points you to one of the .com TLD servers operated by Verisign. There are TLD servers for every extension: .io, .org, .net, .uk, and thousands more. Same deal — they don't know the final IP, but they know which nameserver is authoritative for your specific domain.

Authoritative nameservers are where the actual answer lives. These servers hold the DNS records for a specific domain. When you buy yoursite.com and configure it with a hosting provider, you're pointing to their authoritative nameservers. When someone queries for your domain, it eventually ends up here, and this is where the real IP address is returned.

The Resolution Process

When you type a domain into your browser, here's the exact chain of events.

Step 1 — Browser cache. Your browser checks if it already resolved this domain recently. Chrome caches DNS results for a short window. If the cached entry hasn't expired, the browser uses it directly and the rest of this process never happens.

Step 2 — OS cache. If the browser has no cached answer, it asks the operating system. The OS maintains its own DNS cache and also checks /etc/hosts (on Linux/macOS) or C:\Windows\System32\drivers\etc\hosts (on Windows) — a local file you can use to override DNS entirely for specific domains.

Step 3 — Recursive resolver. If neither local cache has the answer, the OS sends a query to a recursive resolver. This is usually your ISP's DNS server, but many people configure a public one: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), or 9.9.9.9 (Quad9). The recursive resolver does all the heavy lifting described below. It also caches results aggressively, so if anyone else using the same resolver recently looked up the same domain, you get the cached answer instantly.

Step 4 — Root server. If the resolver has no cached answer, it contacts a root server. The root server responds: "I don't know google.com, but here are the .com TLD servers." The resolver now knows where to ask next.

Step 5 — TLD server. The resolver queries the .com TLD server. It responds: "I don't have the IP for google.com, but the authoritative nameservers are ns1.google.com and ns2.google.com."

Step 6 — Authoritative nameserver. The resolver queries ns1.google.com. This is the definitive source. It returns the A record: google.com → 142.250.80.46. The resolver caches this result (respecting the TTL), then returns it to your browser.

Six round trips for a cache miss. One round trip for a cache hit. This is why the first visit to a site can feel slightly slower — DNS is warming up.

DNS Record Types

DNS stores more than just IP addresses. A domain can have several types of records:

Record	Purpose	Example
A	Domain → IPv4 address	example.com → 93.184.216.34
AAAA	Domain → IPv6 address	example.com → 2606:2800:220:1:248:1893:25c8:1946
CNAME	Alias → another domain	www.example.com → example.com
MX	Mail server for domain	example.com → mail.example.com
TXT	Arbitrary text	Used for SPF, DKIM, domain verification
NS	Nameserver records	Delegates domain to specific nameservers

Here's what these look like in a dig query output:

$ dig google.com A

;; ANSWER SECTION:
google.com.    300    IN    A    142.250.80.46

$ dig google.com MX

;; ANSWER SECTION:
google.com.    300    IN    MX    10 smtp.google.com.

$ dig google.com TXT

;; ANSWER SECTION:
google.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ~all"

The number after the domain name (e.g. 300, 3600) is the TTL — more on that next.

TTL — Time To Live

Every DNS record has a TTL value, measured in seconds. This tells recursive resolvers how long to cache the answer before they must fetch a fresh copy.

A record with TTL 300 will be cached for 5 minutes. A record with TTL 86400 will be cached for 24 hours.

The tradeoff is real:

• Low TTL (60–300s) — resolvers re-query more often. If you change your IP, the change propagates quickly. But you generate more DNS traffic and put more load on your nameservers.
• High TTL (3600–86400s) — resolvers cache the answer for hours or days. DNS traffic is low. But when you do change something, it takes a long time for all resolvers globally to pick up the new record.

A common pattern: lower your TTL to 300 seconds a day or two before a planned migration. Once everything is switched over and stable, raise it back to a high value.

DNS Caching

DNS caching happens at multiple independent layers, each with its own cache:

1. Browser — Chrome, Firefox, Safari all cache DNS locally
2. Operating system — systemd-resolved on Linux, mDNSResponder on macOS
3. Recursive resolver — your ISP or public resolver (8.8.8.8, 1.1.1.1)
4. Intermediate routers — some network infrastructure caches DNS

This is why "DNS propagation" takes time. When you update a DNS record, you're updating it on your authoritative nameserver. But every cached copy across these layers has to expire before all users see the new value. If your old TTL was 24 hours, it could take up to 24 hours before everyone globally sees your change.

You can check what your resolver currently has cached using dig +trace google.com — this forces the resolver to walk the full hierarchy from root servers instead of using its cache.

DNS Security

DNS was designed in the 1980s without security in mind. Several attack classes emerged:

DNS spoofing / cache poisoning — an attacker injects a false DNS record into a resolver's cache. When users query that resolver, they get sent to a fake IP instead of the real one. Classic man-in-the-middle setup.

DNSSEC (DNS Security Extensions) — cryptographic signatures on DNS records. Each record is signed with a private key, and resolvers can verify the signature using the corresponding public key. This prevents tampering in transit. DNSSEC is supported but not universally deployed.

DNS over HTTPS (DoH) — your DNS queries are sent over HTTPS instead of plain UDP port 53. This prevents your ISP (or anyone on your network) from seeing what domains you're looking up. Cloudflare's 1.1.1.1 and Google's 8.8.8.8 both support DoH. Modern browsers can be configured to use it directly.

DNS over TLS (DoT) — same idea as DoH but uses port 853 with TLS encryption instead of wrapping DNS in HTTP.

Real-World DNS

Cloudflare 1.1.1.1 is the most popular public DNS resolver in the world by query volume. It caches aggressively, returns answers in under 1ms for cached entries, and supports DoH and DoT. Cloudflare publishes response time statistics — the resolver typically beats ISP resolvers by 5–30ms on average latency.

AWS Route 53 is the DNS service used by most AWS-hosted applications. Beyond basic DNS, it supports routing policies: latency-based routing (send users to the nearest region), weighted routing (send 90% of traffic to v2 and 10% to v1), health-check failover (automatically stop returning an IP if the server behind it goes down), and geolocation routing. These features turn DNS into a layer of traffic management, not just name resolution.

Key Takeaways

• DNS is a hierarchical, distributed system: root servers → TLD servers → authoritative nameservers
• Resolution involves up to 6 round trips on a cache miss; 1 round trip on a cache hit
• The recursive resolver (your ISP or 8.8.8.8) does most of the work and caches results
• TTL controls how long resolvers cache an answer — low TTL enables fast changes, high TTL reduces query load
• DNS caching happens at multiple layers: browser, OS, resolver — which is why propagation takes time
• DNSSEC adds cryptographic verification; DoH and DoT encrypt the queries themselves

Next up: how the actual HTTP communication between your browser and server works — and why encrypting it with HTTPS matters.