DNS Explained: How the Internet Finds Websites

Every time you type a URL into your browser, something invisible happens before the page loads. Your computer needs to find the actual server hosting that website. The address you typed (google.com) is just a name — the internet works with numbers.

DNS — the Domain Name System — is the phone book that converts names to numbers. Understanding it helps you design faster, more reliable systems.

The Problem DNS Solves

Servers on the internet are identified by IP addresses, like 142.250.185.14. Humans can't remember these. We remember names like google.com.

DNS sits in the middle, translating names to numbers. Without it, you'd need to memorize IP addresses for every site you visit.

But it's not just a lookup table. DNS is a massive distributed system handling billions of queries per day across millions of servers worldwide. That scale is why it's designed the way it is.

How a DNS Lookup Works (Step by Step)

When you type example.com in your browser, here's what actually happens:

Step 1: Check the local cache

Your computer first checks its own memory. If you visited example.com recently, the answer is already stored. This is instant.

Step 2: Ask the recursive resolver

If there's no cache hit, your computer asks a DNS resolver — usually run by your ISP or a public service like Cloudflare (1.1.1.1) or Google (8.8.8.8). The resolver's job is to find the answer for you.

Step 3: Resolver asks the root servers

The resolver asks one of 13 root server clusters: "Who knows about .com domains?" The root server points to the .com TLD (Top Level Domain) servers.

Step 4: Ask the TLD servers

The .com servers know which name servers are responsible for example.com. They point the resolver there.

Step 5: Ask the authoritative name server

The authoritative name server has the actual record. It returns the IP address: "example.com is at 93.184.216.34."

Step 6: Return and cache

The resolver gives your browser the IP address. Your browser connects. The resolver caches the answer for next time.

This sounds like a lot of steps, but it usually completes in under 100 milliseconds. And once cached, it's instant.

DNS Record Types You'll Actually Use

DNS stores different types of records for different purposes:

As a backend developer, you'll deal with A records (pointing your domain to your server), CNAME records (subdomains, CDN setup), and TXT records (SSL verification, email authentication).

TTL: How Long Records Are Cached

Every DNS record has a TTL (Time To Live) — a number in seconds that says "cache this answer for this long."

example.com  300  IN  A  93.184.216.34
                 ↑
           TTL = 300 seconds (5 minutes)

Short TTL (60–300 seconds): Changes propagate fast. Use this before migrations. Long TTL (3600–86400 seconds): Reduces DNS query load. Use for stable records.

When you're moving servers, drop your TTL to 60 seconds a day before the move. Then after the switch, you can raise it back up.

DNS in System Design

DNS does more than just name resolution. System designers use it actively:

Load balancing: Return multiple A records for the same domain. Clients pick one, spreading load.

api.example.com  60  A  10.0.0.1
api.example.com  60  A  10.0.0.2
api.example.com  60  A  10.0.0.3

Geographic routing: Different IP addresses based on where the query comes from. Users in Europe get European servers. This is how CDNs work.

Failover: If your primary server goes down, your monitoring system updates the DNS record to point to a backup. With a low TTL, this can take effect in minutes.

Service discovery: In microservices, Kubernetes uses internal DNS so services can find each other by name rather than hardcoded IP addresses.

Common DNS Issues and How to Debug Them

Propagation delays: DNS changes don't happen instantly. Old records are cached around the world. Use dig or nslookup to check what different resolvers see:

# Check what Google's resolver sees
dig @8.8.8.8 example.com
 
# Check what Cloudflare's resolver sees
dig @1.1.1.1 example.com
 
# See the full resolution chain
dig +trace example.com

Cache poisoning: Attackers inject false DNS records, redirecting users to malicious servers. DNSSEC (DNS Security Extensions) adds cryptographic signatures to prevent this.

DDoS on DNS: Attackers overwhelm DNS servers with queries. This is why critical services use multiple DNS providers and anycast routing.

Key Takeaways

• DNS translates human-readable names to IP addresses across a distributed hierarchy
• A typical lookup: local cache → recursive resolver → root → TLD → authoritative server
• TTL controls how long records are cached — lower TTL before server migrations
• DNS can load balance, route geographically, and enable fast failover
• dig +trace example.com shows you the full resolution chain for debugging

DNS seems simple until something breaks. Understanding the full resolution process means faster debugging and better system design decisions.

Related reading: OSI Model Explained · Network Protocols: TCP, UDP, HTTP