How DNS Works: The Internet's Phone Book

Section to Expand: DNS: The Internet's Phone Book

Here's the thing: computers are fundamentally lazy. They want numbers — IP addresses like 151.101.65.121. But humans? We're allergic to numbers. We want names. reddit.com. google.com. Something has to translate between these two worlds, and that something is DNS: the Domain Name System.

DNS is one of those pieces of infrastructure that's so fundamental, so essential, that when it works — and it usually does — you never think about it. You type a name, and the website appears. Magic. But when DNS breaks? Everything breaks. Your email doesn't work. You can't access any websites. It's like the entire internet just vanished. And in a way, it has, because without the ability to translate names into numbers, the web becomes useless to you.

The Domain Name Hierarchy

Domain names follow a hierarchical structure, and here's the key: you read them right to left.

www.example.com. ← (notice that trailing dot? That's the "root")

• . (the root): The very top of the DNS tree — literally everything belongs here
• com: A Top-Level Domain (TLD), managed by a company called Verisign
• example: The second-level domain — the part you actually go buy from a registrar
• www: A subdomain of example.com, set up by whoever controls example.com

There are over 1,500 TLDs floating around now. You've got the classics — .com, .net, .org — country codes like .uk, .de, .jp, and then the newer playgrounds like .io, .dev, .app. Every few years, ICANN (the organization that basically runs this whole show) approves new ones.

graph TD
    ROOT[". (Root)"]
    ROOT --> COM[".com"]
    ROOT --> NET[".net"]  
    ROOT --> ORG[".org"]
    ROOT --> UK[".uk"]
    COM --> EXAMPLE["example.com"]
    COM --> GOOGLE["google.com"]
    EXAMPLE --> WWW["www.example.com"]
    EXAMPLE --> MAIL["mail.example.com"]
    EXAMPLE --> API["api.example.com"]

Why Hierarchy Matters

Here's where it gets clever. Instead of one massive, centralized database containing every single domain on the internet — which would be a nightmare to maintain, impossible to search quickly, and prone to catastrophic failure — the system distributes responsibility across layers. The root servers don't need to know about your blog. They only need to know: "Who manages .com?" The .com servers don't need to know about your subdomains. They only need to know: "Who manages yourblog.com?" This delegation is what allows DNS to scale to billions of names without collapsing.

Think of it like the postal system. The international postal authority doesn't memorize every address on Earth. It just knows which country each address belongs to. That country's postal system knows which region. The region knows which town. The town knows the street and house number. DNS works exactly the same way — each level only knows its children and delegates the rest upward. It's elegant.

The DNS Resolution Process

So what actually happens when you type www.example.com into your browser? This is one of the most instructive walkthroughs in all of networking, because it reveals how much coordination happens in the background.

Step 1 — Check the local cache: Your browser asks itself: "Have I looked up www.example.com recently?" It probably has, and that answer is sitting in memory. If the cached entry hasn't expired yet — we'll get to expiration times in a moment — the browser uses it. Done. No network trips needed.

This is why DNS is so fast in practice. Yes, the very first time you visit a website, you have to go through all the steps below. But you don't do it twice. Modern browsers also do something called DNS prefetching: they'll automatically resolve the names of resources linked on the current page before you even click anything, warming up the cache so it's ready when you navigate.

Step 2 — Check the OS cache: If the browser doesn't have it, it asks the operating system. Your OS maintains its own DNS cache, and it also consults a file called /etc/hosts (on Linux and Mac) or C:\Windows\System32\drivers\etc\hosts (on Windows). This file is ancient — it's a leftover from the pre-DNS internet when people actually manually edited text files to map hostnames to addresses. Wild, right? But it's still useful.

Developers use this file all the time. Want to test your website locally before it goes live? Add a line like 127.0.0.1 staging.example.com to your hosts file, and your browser treats staging.example.com as pointing to your local machine. The hosts file takes absolute priority over everything else in DNS, so it's a perfect test tool.

Step 3 — Ask the Recursive Resolver: If nobody locally knows the answer, the OS contacts a Recursive Resolver, sometimes called a Recursive Nameserver. This server — typically run by your ISP, or by Google (8.8.8.8), Cloudflare (1.1.1.1), or your company's internal DNS team — is the workhorse of the entire DNS system. It's going to do the hard work of tracking down the answer.

Your ISP's recursive resolver usually gets configured automatically when you connect to the internet. Some ISPs have gotten flak over the years for poor DNS service — slow responses, injecting ads, sketchy privacy policies. That's why tons of people use public resolvers instead. Google and Cloudflare offer public DNS services with better performance, and some of them (like Cloudflare's 1.1.1.1) encrypt your queries so your ISP can't see which sites you're visiting. It's a privacy win.

Step 4 — The resolver asks a Root Server: The recursive resolver now contacts one of 13 sets of Root Name Servers — these are operated by different organizations around the globe and identified with letters: a.root-servers.net through m.root-servers.net. The resolver says: "Who knows about www.example.com?" The root server doesn't have the full answer, but it knows who manages .com. It says: "Go ask this TLD server instead."

There are actually way more than 13 physical servers behind those names. They're distributed around the world using anycast routing, a clever technique that ensures your query gets routed to the nearest physical server. This redundancy is critical — if all the root nameservers went down simultaneously, the internet would grind to a halt. They're protected accordingly, and they've been attacked before. Each attack has been defended.

Step 5 — Ask the TLD Nameserver: The resolver asks the .com TLD server: "Which nameservers are authoritative for example.com?" The TLD server doesn't know www.example.com's IP, but it knows who does. It returns the addresses of example.com's nameservers.

These TLD servers are also replicated and distributed. There are separate sets for .com, .org, .net, every country code, and every new generic TLD. ICANN coordinates this entire infrastructure.

Step 6 — Ask the Authoritative Nameserver: The resolver asks example.com's authoritative nameserver — the one actually responsible for example.com — "What is the IP address for www.example.com?" This nameserver is controlled by whoever owns example.com, and it has the definitive answer. It responds with something like: www.example.com. 300 IN A 93.184.216.34.

The authoritative nameserver is where the buck stops. When you register a domain and configure DNS records through your registrar's web panel, you're telling the TLD servers which authoritative nameserver to delegate to. That might be your registrar's own servers, your web hosting provider's, or a separate DNS service like Route 53, Cloudflare, or Azure DNS.

Step 7 — Cache and return: The resolver caches this answer for 300 seconds (as specified by the TTL), then returns the IP to your computer. Your browser now has what it needs — it can start making HTTP requests.

Each layer in this chain also caches the answer according to the TTL, so future requests move faster. If your browser asks again within 300 seconds, maybe your OS has it cached. If the resolver has been asked about www.example.com a lot recently, it has the answer cached without needing to ask the authoritative server again.

sequenceDiagram
    participant B as Browser
    participant OS as OS/Local Cache
    participant R as Recursive Resolver (ISP)
    participant Root as Root Nameserver
    participant TLD as .com TLD Server
    participant Auth as Authoritative NS (example.com)
    
    B->>OS: What's www.example.com?
    OS-->>B: Not in cache
    OS->>R: What's www.example.com?
    R->>Root: Who handles .com?
    Root-->>R: Ask 192.5.6.30 (Verisign)
    R->>TLD: Who handles example.com?
    TLD-->>R: Ask 205.251.196.1 (example's NS)
    R->>Auth: What's www.example.com?
    Auth-->>R: 93.184.216.34 (TTL: 300s)
    R-->>OS: 93.184.216.34 (caching for 300s)
    OS-->>B: 93.184.216.34

The whole chain from "browser asks" to "browser gets an IP" usually takes between 20 and 120 milliseconds. After that, the answer sits in cache and you get instant lookups.

A Common Misconception: DNS and IP Changes

Here's something that trips up a lot of developers: they think that when you change a domain's IP address in DNS, it takes effect everywhere instantly. But that's not how it works. Your change is live immediately at the authoritative nameserver, sure. But anyone who looked up your domain recently still has the old answer cached. The worst-case scenario? Everyone sees your old IP for however long you set the TTL to. If your TTL was 24 hours and you didn't lower it before making the change, some visitors might see the old IP for up to 24 hours after you flip the switch.

This is why you see experienced engineers lowering the TTL to something like 5 minutes before making critical changes. It means when you do make the change, it propagates in minutes instead of hours.

DNS Record Types

DNS stores way more than just IP addresses. Different record types handle different jobs:

As a developer, you'll spend most of your time with A records (pointing your domain to your server), CNAME records (creating subdomains), MX records (email setup), and TXT records (proving you own the domain or configuring email security).

Understanding CNAME Records in Depth

A CNAME is an alias. If you create a CNAME record that says "www.example.com points to example.com," both names resolve to the same IP. But here's the constraint: you can't have a CNAME and another record type on the same name. You can't have both a CNAME and an MX record, for example. This is why the root of your domain — just example.com by itself — uses an A record instead of a CNAME. You need that MX record for email to work.

Where CNAME really shines is with subdomains. If you've got api.example.com, blog.example.com, and shop.example.com all pointing to the same hosting provider, you can CNAME each one to the provider's hostname. Then if you change hosts someday, you update one A record and all the aliases follow along automatically.

TXT Records: The Swiss Army Knife of DNS

TXT records are meant for arbitrary text, but they've become essential for modern internet operations:

• SPF (Sender Policy Framework): You publish a TXT record listing which mail servers are authorized to send email on behalf of your domain. This prevents attackers from spoofing email that claims to come from you.
• DKIM (DomainKeys Identified Mail): You publish public keys as TXT records so mail receivers can cryptographically verify that emails claiming to be from you actually came from your authorized mail server.
• DMARC (Domain-based Message Authentication, Reporting and Conformance): A TXT record that tells receivers what to do when SPF or DKIM checks fail.
• Domain verification: Google, Microsoft, AWS, and tons of other services ask you to prove you own a domain by adding a specific TXT record. They then check DNS to confirm you put it there.

TTL: Why DNS Changes Take Time to Propagate

Every DNS record has a TTL (Time to Live) — measured in seconds. This is how long resolvers should cache the answer. If your example.com A record has a TTL of 86400, that's 24 hours. Resolvers that looked it up today won't check for updates until tomorrow.

This is why DNS changes propagate slowly. Every resolver that cached your old answer has to wait for that TTL to expire before it'll query again and get your new answer. If you're about to change your domain's IP, best practice is to lower the TTL a day or two beforehand, then make the change, then raise it again.

TTL Trade-offs

Picking the right TTL is a classic engineering trade-off:

• Low TTL (5 minutes to 1 hour): Changes spread quickly, which is great when you're actively troubleshooting or making frequent updates. The downside: your authoritative nameservers get hammered with more queries, more traffic, more load.
• High TTL (24 hours or longer): Changes spread slowly, but your nameservers barely break a sweat. Less traffic, better performance for users whose resolvers cache the answer longer and avoid repeated queries.

Most people land somewhere in the middle: 1 to 6 hours for normal records, then they dial it down temporarily if they're about to make a change.

DNS in Practice: Real-World Scenarios

Scenario 1: Load Balancing with DNS

Some services use DNS round-robin for load balancing. When your authoritative nameserver returns multiple A records for the same name, you might get back an array: [10.0.0.1, 10.0.0.2, 10.0.0.3]. Different resolvers might return them in different orders, or rotate them, and different clients use different strategies to pick which one to actually connect to. It's a simple, elegant form of load balancing — though it has limitations. DNS doesn't know if a server is healthy, just that it exists.

Scenario 2: Subdomain Delegation

Say you own example.com and you want another team to manage team.example.com independently. You add NS records delegating authority. Your DNS for example.com says: "For anything under team.example.com, ask these other nameservers." That team can then manage their subdomain's records without you being in the middle, and you don't have to worry about their configuration.

Scenario 3: Debugging DNS Issues

When DNS doesn't work, you can debug with command-line tools:

• dig example.com shows A records
• dig MX example.com shows mail records
• dig +trace example.com walks through the entire resolution path, showing you which nameserver returned which answer and if anything is broken

This lets you see the full picture — which server is responding, if there's a mismatch, or if a delegated server is down.

DNS and Security

Here's something to keep in mind: DNS was originally unencrypted and unauthenticated. An attacker on your network could intercept your DNS queries and return fake IP addresses, redirecting you to whatever malicious site they wanted. Modern solutions have emerged to address this:

• DNSSEC: Digital signatures on DNS records, so you can cryptographically prove a record hasn't been tampered with.
• DNS over HTTPS (DoH) and DNS over TLS (DoT): Both encrypt your DNS queries so your ISP or network administrator can't spy on which sites you're visiting.

These are becoming more common, though adoption is still uneven depending on where you are. But here's the key insight: DNS is a critical security foundation. It's the layer that everything else trusts. If DNS is compromised, the trust in the entire internet breaks down. Understanding that — and building systems accordingly — is crucial.