DNS: How the Internet's Phone Book Works

The Phonebook You Never Open

Before smartphones, people memorised important phone numbers. Your best friend, your parents, the pizza place — you knew them by heart. Then contact lists arrived, and suddenly nobody remembered numbers anymore. You just typed "Mom" and tapped call.

The internet has the same problem. Every website lives at a numerical IP address — Google's servers are at 142.250.80.46, this works but nobody types that. You type "google.com" and your computer silently translates it to the right numbers in milliseconds. That translation system — the Domain Name System — is one of the most important and least visible parts of the internet. Developed by Paul Mockapetris in 1983 and formalised in RFC 1034 and RFC 1035, DNS is a globally distributed, hierarchical database that handles over a trillion queries per day.

The DNS Hierarchy

DNS is not a single server somewhere holding all domain names. It's a tree-shaped hierarchy of servers, each responsible for their portion of the namespace:

                        . (Root)
                       / \
                     /     \
                   .com    .org    .net    .io  ...  (TLDs)
                  /    \
           google.com  amazon.com  ...  (Second-level domains)
              /
         mail.google.com  (Subdomain)

Root servers are at the top. There are 13 logical root server addresses (labelled A through M), operated by organisations like NASA, ICANN, and Verisign — though each is actually a cluster of hundreds of physical machines distributed worldwide via anycast.

TLD (Top-Level Domain) servers handle .com, .org, .net, .uk, and so on. ICANN's IANA manages which organisations operate which TLDs.

Authoritative nameservers hold the actual DNS records for specific domains. When you register google.com, you configure authoritative servers that know all of Google's IP addresses.

The DNS Resolution Process: Step by Step

When you type www.google.com in your browser, the following sequence happens — typically in under 50 milliseconds:

Browser ──1──> Browser DNS Cache
       ──2──> OS Cache / hosts file
       ──3──> Recursive Resolver (ISP or 8.8.8.8)
                     │
              4. Asks Root Server: "Who handles .com?"
              5. Root says: "Ask the .com TLD server at 192.5.6.30"
              6. Asks TLD Server: "Who handles google.com?"
              7. TLD says: "Ask Google's NS at 216.239.32.10"
              8. Asks Authoritative: "What's www.google.com?"
              9. Gets back: 142.250.80.46
                     │
       <──────────────
Browser caches result, connects to 142.250.80.46

Step 1 — Browser cache: Chrome, Firefox, and other browsers cache DNS results internally. You can see Chrome's DNS cache at chrome://net-internals/#dns.

Step 2 — OS cache and hosts file: Your operating system maintains its own DNS cache. It also checks the hosts file (C:\Windows\System32\drivers\etc\hosts on Windows, /etc/hosts on Linux/Mac) — a local override that takes priority over DNS. Many ad-blockers and parental control tools work by adding entries here.

Step 3 — Recursive resolver: If the OS cache misses, the query goes to a recursive resolver — usually provided by your ISP, or a public resolver like Google's 8.8.8.8 or Cloudflare's 1.1.1.1. The resolver does the heavy lifting of querying other servers on your behalf.

Steps 4–9 — The recursion: The resolver works down the tree: root → TLD → authoritative, until it gets the final answer.

Caching: Each response includes a TTL (Time to Live) value in seconds. The resolver caches the result and serves it to all clients who ask until the TTL expires, then re-queries. Low TTLs (60s) allow faster updates; high TTLs (86400s = 24h) reduce load.

DNS Record Types

DNS is more than just name-to-IP translation. The database stores multiple record types:

CNAME chains are common but costly — each CNAME requires an additional lookup. Deeply nested CNAME chains can slow DNS resolution noticeably.

TTL: The Freshness Timer

Every DNS record has a TTL measured in seconds. When your resolver caches a result, it won't query again until the TTL expires:

Query result: 142.250.80.46  TTL: 300
              │
              ├── Cached for 300 seconds (5 minutes)
              ├── Any client asking during this time gets the cached answer
              └── After 300s: resolver queries the authoritative server again

Choosing TTL values involves a trade-off:

• Short TTL (60–300s): Changes propagate quickly, useful for failover and migrations. Higher load on nameservers.
• Long TTL (3600–86400s): Less DNS traffic, faster responses from cache. Changes take longer to propagate globally.

Querying DNS Yourself

Two essential tools for DNS diagnostics:

nslookup (available on Windows, Mac, Linux):

nslookup google.com
# Returns: Name: google.com, Address: 142.250.80.46

nslookup -type=MX gmail.com
# Returns mail server records

dig (Linux/Mac, more detailed output):

dig google.com
dig google.com AAAA          # IPv6 record
dig +trace google.com        # Shows full resolution path
dig @8.8.8.8 example.com    # Query specific resolver

The +trace flag in dig is particularly useful — it shows you every step from root server to authoritative answer, making the hierarchy visible.

DNS over HTTPS (DoH): Privacy Protection

Traditional DNS queries are sent in plain text over UDP port 53. Anyone between you and your resolver — your ISP, a coffee shop Wi-Fi operator — can see every domain you visit, even if the actual web traffic is encrypted with HTTPS.

DNS over HTTPS (DoH) — defined in RFC 8484 (2018) — solves this by sending DNS queries inside normal HTTPS connections. From a network observer's perspective, DNS lookups are indistinguishable from regular web traffic.

Traditional DNS:
Browser ──UDP:53, plaintext──> Resolver
         (ISP can read "you queried google.com")

DNS over HTTPS:
Browser ──HTTPS:443, encrypted──> DoH Resolver (e.g., 1.1.1.1)
         (ISP sees only: "encrypted traffic to 1.1.1.1")

Firefox enables DoH by default for US users, routing queries to Cloudflare. Chrome supports it when using compatible resolvers. The trade-off is that privacy shifts from your ISP to your DoH provider — so trust in the provider matters.

Summary

DNS is the distributed, hierarchical system that translates human-readable domain names into machine-readable IP addresses. The resolution process flows from browser cache to OS cache to recursive resolver to root, TLD, and authoritative servers. DNS records come in many types beyond simple A records — MX for email, CNAME for aliases, TXT for verification. TTL controls how long results are cached. Tools like dig and nslookup let you inspect DNS in real-time, and DNS over HTTPS is increasingly standard for privacy protection. DNS is the phonebook that makes the modern internet usable.