DNS: The Phone Book That Runs the Internet

You type "google.com" into your browser. Less than a second later, Google's homepage appears. What happened in that second involves a distributed system that handles trillions of lookups per day, operates across thousands of servers worldwide, and is so reliable that most people don't know it exists.

That system is DNS — the Domain Name System. It's the reason you can type "google.com" instead of "142.250.80.46." It translates human-readable names into machine-readable addresses, and it does it so seamlessly that you only notice when it breaks.

The Problem DNS Solves

Computers on the internet communicate using IP addresses — numerical identifiers like 142.250.80.46 (IPv4) or 2607:f8b0:4004:800::200e (IPv6). These are fine for computers. They're terrible for humans.

DNS is the translation layer. You provide a domain name. DNS returns the IP address. Your browser connects to that IP address. The website loads.

This is the same concept as a phone book: you look up a name and get a number. Except this phone book is distributed across the entire internet, handles billions of lookups per second, and updates in near-real-time when entries change.

How a DNS Lookup Works

When you type "blog.example.com" into your browser, here's what happens:

Step 1: Check the Cache

Your browser checks its own cache first. If you visited this site recently, the IP address is already stored locally. Lookup done in microseconds.

If not in the browser cache, your operating system checks its cache. Same idea — recently resolved names are stored.

If neither cache has the answer, the query goes to your DNS resolver — typically your ISP's DNS server, or a public resolver like Google (8.8.8.8) or Cloudflare (1.1.1.1).

Step 2: The Resolver Asks Around

The resolver doesn't know the answer either (or its cache expired). It starts a chain of questions:

"Who handles .com?" → The resolver asks a root nameserver (one of 13 root server clusters that know the top-level domain servers). The root says: "The .com nameservers are at these addresses."

"Who handles example.com?" → The resolver asks a .com nameserver. It responds: "The nameservers for example.com are ns1.example.com and ns2.example.com, at these addresses."

"What's the IP for blog.example.com?" → The resolver asks example.com's nameserver. It responds: "blog.example.com is at 93.184.216.34."

Step 3: Return and Cache

The resolver returns the IP address to your browser and caches the result. The browser connects to 93.184.216.34. The page loads.

This entire chain — root server, TLD server, authoritative server — takes 50-200 milliseconds. Cached lookups take under 1 millisecond. You never notice.

DNS Records: What You Actually Configure

When you own a domain, you configure DNS records that tell the world where your services live.

A Record

Maps a domain name to an IPv4 address.

example.com.    A    93.184.216.34

"When someone asks for example.com, send them to this IP address."

AAAA Record

Same as A, but for IPv6 addresses.

example.com.    AAAA    2606:2800:220:1:248:1893:25c8:1946

CNAME Record

Maps a domain name to another domain name (an alias).

www.example.com.    CNAME    example.com.
blog.example.com.   CNAME    my-app.vercel.app.

"When someone asks for blog.example.com, look up my-app.vercel.app instead." The CNAME is an indirection — the final IP comes from wherever the target resolves to.

MX Record

Specifies the mail servers for a domain.

example.com.    MX    10    mail.example.com.

"When someone sends email to @example.com, deliver it to mail.example.com." The number (10) is a priority — lower numbers are tried first.

TXT Record

Stores arbitrary text. Used for domain verification, email authentication (SPF, DKIM, DMARC), and other metadata.

example.com.    TXT    "v=spf1 include:_spf.google.com ~all"

"Here's our email authentication policy." Google, Microsoft, and other services use TXT records to verify that you own a domain.

NS Record

Specifies which nameservers are authoritative for a domain.

example.com.    NS    ns1.example.com.
example.com.    NS    ns2.example.com.

"If you want to know about example.com, ask these nameservers."

TTL: How Long Answers Last

Every DNS record has a TTL (Time to Live) — the number of seconds a resolver should cache the answer before asking again.

example.com.    A    93.184.216.34    TTL: 3600

TTL 3600 means: cache this answer for 1 hour. After that, ask again.

High TTL (hours to days): Fewer DNS lookups, lower load on nameservers, but changes propagate slowly. Good for stable records that rarely change.

Low TTL (minutes): Changes propagate quickly, but more DNS lookups happen. Good when you're about to make a change and want it to take effect fast.

The common mistake: Setting TTL to 86400 (24 hours) and then wondering why a DNS change doesn't take effect. The old answer is cached everywhere for up to 24 hours. Before making DNS changes, lower the TTL in advance, wait for the old TTL to expire, then make the change.

Why DNS Matters for Developers

Custom Domains

When you deploy to Vercel, Render, or any hosting platform, they give you a URL like my-app.vercel.app. To use your own domain (myapp.com), you create a CNAME or A record pointing your domain to their servers.

Email Setup

If your domain sends email, you need MX records (where to deliver mail), SPF records (who's allowed to send as you), and DKIM records (email signature verification). Missing these means your email goes to spam.

SSL Certificates

Certificate authorities verify domain ownership through DNS. Let's Encrypt, for example, can verify you own a domain by checking for a specific TXT record. This is how automated SSL works.

Debugging

When a website doesn't load, the first question is often: "Is it a DNS problem?" Tools help:

# Look up a domain's A record
nslookup example.com

# Detailed DNS query
dig example.com

# Check DNS propagation across the world
# (use online tools like dnschecker.org)

If dig returns the right IP but the site doesn't load, DNS is working — the problem is elsewhere. If dig returns nothing or the wrong IP, DNS is the problem.

Key Takeaway

DNS translates domain names to IP addresses through a hierarchical system of nameservers. Your DNS records — A for IP addresses, CNAME for aliases, MX for email, TXT for verification — tell the world where your services live. TTL controls how long answers are cached. When you buy a domain and deploy a service, configuring DNS correctly is what connects them. When things don't load, checking DNS is always the first step.