DNS Explained – How Domain Names Get Resolved

> Without DNS, you'd need to memorize IP addresses for every website.

This used to be true until virtual hosting came along, allowing for several domains to point to the same IP address, but only for non-HTTPS traffic. Then a bit later we got SNI (Server Name Indication) that did the same thing for HTTPS.

I remember having web servers with 10-12 public IP adresses when I started working. The number of IPv4 addresses needed has been greatly reduced since.

I have to admit - I still grind my teeth every time I see "dns propagation" used without a direct follow-up that it's a myth, you're looking at cascading cache expiry.

Propagation might be a useful way to visualise it, but doesn't match reality unless every cache is a warm cache.

The biggest issue with DNS is not the protocol, or even the reference implementation. It's the people who think they are clever and try to make things better by making them worse.

The most egregious of course is ISPs rewriting TTLs (or resolvers that just ignore them). But there are other implementation issues too, like caching things that shouldn't be or doing it wrong. I've seen resolvers that cache a CNAME and the A record it resolves to with the TTL of the CNAME (which is wrong).

I'm also very concerned about the "WHY DNS MATTERS FOR SYSTEM DESIGN" section. While everything there is correct enough, it doesn't dive into the implication of each and how things go wrong.

For example, using DNS for round robin balancing is an awful idea in practice. Because Comcast will cache one IP of three, and all of a sudden 60% of your traffic is going to one IP. Similar issue with regional IPs. There are so many ways for the wrong IP to get into a cache.

There is a reason we say "it's always DNS".

> You can change which resolver you use in your network settings. I switched to 1.1.1.1 on my machines - it's noticeably faster than my ISP's default resolver.

Noticeably faster as in just loading a website? Or in some script where small differences add up? I thought typical DNS lookup was sub 100ms, but I've never tried switching my resolver so I'm curious

I really like Julia Evan's explainer on this as well: https://wizardzines.com/zines/dns/

> DNS broke my site for three hours. But now I actually understand it

I have been broken for three decades and I still don't understand DNS. It is a simple protocol but people use it in complicated manners.

well written

would really be happy to have had these explanations before I had to figure it out for myself.

then you have these guys who reached the next level

https://www.dns.toys/

Only oddity was the reference to the "router cache". I agree if your browser tried to lookup example.com the local cache would be used, but then it would be the system's configured DNS server - and that would most likely be an ISP, rather than your local router.

(Assuming a typical home connection, your router is _probably_ not a DNS server with local cache, it probably is a DHCP server which will hand out the upstream/ISPs' nameservers.)

This is not a bad overview of DNS from a theoretical perspective. It’s also pretty well written and has good examples and figures.

What I think is missing is a bit more of the “in practice” side. If the author was surprised about TTL values, I doubt they have much experience with some of the other pitfalls, so I’m not surprised (not a knock on the author). But there is a reason why the phrase “It’s always DNS” exists.

As an example, it could be helpful to mention that ISP DNS resolvers (or any caching resolver in the path) could decide to ignore the TTL. In this case, your 360 sec TTL might not get updated for an hour or a day or longer. This can be infuriating to troubleshoot.

A section on troubleshooting might also be beneficial. But this mainly consists of checking results from different resolvers in your path - does it work with a local resolver? Your ISPs DNS? The authoritative server?

Honestly, I guess it's a fine article for someone who isn't very technical, but it provides very little real detail, and this wasn't an example of DNS breaking anything - it worked as designed.

The biggest pain of DNS for most people is if someone has set the TTL to an absurdly large number, or if a resolver isn't respecting TTL. And once you get into advanced configurations, SOAs and delegation certainly create their own headaches!

This might be the easiest-to-understand breakdown of DNS that I've seen to date. I've owned a domain since the late 90s, but never really understood everything the acronyms or concepts involved in making it work. Well done!

Well written! Is so easy to understand and read that I can easily share it even with non-tech people c:

DNS is an example of a globally distributed DB

Well written article!

> DNS broke my site for three hours. But now I actually understand it

I have been broken for three decades and I still don't understand DNS. It is a simple protocol but people use it in complicated manners.

This is not a bad overview of DNS from a theoretical perspective. It’s also pretty well written and has good examples and figures.

Honestly, I guess it's a fine article for someone who isn't very technical, but it provides very little real detail, and this wasn't an example of DNS breaking anything - it worked as designed.

I have to admit - I still grind my teeth every time I see "dns propagation" used without a direct follow-up that it's a myth, you're looking at cascading cache expiry.

Propagation might be a useful way to visualise it, but doesn't match reality unless every cache is a warm cache.

Yes! The idea of DNS records "propagating" gave me entirely the wrong mental model of DNS very early in my career. Granted, the confusion didn't last long because I read the cricket book soon after, but it was still pretty jarring.

(Assuming a typical home connection, your router is _probably_ not a DNS server with local cache, it probably is a DHCP server which will hand out the upstream/ISPs' nameservers.)

I would argue the contrary - most home routers are running a DNS server of some kind. They forward to upstream, but will resolve local names like your printer and whatnot.

dnsmasq is the defacto tool on these embedded devices for dhcp+dns.

I think this is probably quite dependent on what’s normal for ISPs in the region. In the UK for example, every ISP router I’ve had runs a DNS server and it’s that which is given out via DHCP. It then forwards onto the ISPs DNS platform.

My parents are with Bell (the biggest ISP in Canada) and use the Bell Gigahub (Router/AP/Switch in one). It does have a DNS cache and the its set as the DNS resolver in their DHCP configuration.

The system's configured DNS resolver is usually your router.

I would argue the contrary - most home routers are running a DNS server of some kind. They forward to upstream, but will resolve local names like your printer and whatnot.

dnsmasq is the defacto tool on these embedded devices for dhcp+dns.

The system's configured DNS resolver is usually your router.

My parents are with Bell (the biggest ISP in Canada) and use the Bell Gigahub (Router/AP/Switch in one). It does have a DNS cache and the its set as the DNS resolver in their DHCP configuration.

Thanks! That was exactly what I was going for - making DNS approachable for everyone, not just sysadmins. Glad it helped!

Well written! Is so easy to understand and read that I can easily share it even with non-tech people c:

Appreciate it! That's the goal - tech concepts shouldn't need a CS degree to understand.

Well written article!

Glad you liked it. Thank you

In Scotland I was with Telewest, then Virgin, and my memory is always that the DHCP pushed out the external IP of the ISP's DNS servers.

Nowadays I'm in Finland and definitely the router runs no DNS service, the DHCP service advertises the ISP resolvers.

Probably depends on the region/ISP I guess, but I had no expectation that it would be the more common option.

Thanks! That was exactly what I was going for - making DNS approachable for everyone, not just sysadmins. Glad it helped!

Appreciate it! That's the goal - tech concepts shouldn't need a CS degree to understand.

In Scotland I was with Telewest, then Virgin, and my memory is always that the DHCP pushed out the external IP of the ISP's DNS servers.

Nowadays I'm in Finland and definitely the router runs no DNS service, the DHCP service advertises the ISP resolvers.

Probably depends on the region/ISP I guess, but I had no expectation that it would be the more common option.

Glad you liked it. Thank you

well written

would really be happy to have had these explanations before I had to figure it out for myself.

then you have these guys who reached the next level

https://www.dns.toys/

I really like Julia Evan's explainer on this as well: https://wizardzines.com/zines/dns/

DNS is an example of a globally distributed DB

> Without DNS, you'd need to memorize IP addresses for every website.

I remember having web servers with 10-12 public IP adresses when I started working. The number of IPv4 addresses needed has been greatly reduced since.

You'd still need to memorize the IP address without DNS, otherwise how would you know to which server to connect?

The fact that a server can serve multiple vhosts and do TLS cert selection via SNI is not related to the lookup of what server to connect to.

> You can change which resolver you use in your network settings. I switched to 1.1.1.1 on my machines - it's noticeably faster than my ISP's default resolver.

Noticeably faster as in just loading a website? Or in some script where small differences add up? I thought typical DNS lookup was sub 100ms, but I've never tried switching my resolver so I'm curious

The biggest issue with DNS is not the protocol, or even the reference implementation. It's the people who think they are clever and try to make things better by making them worse.

I'm also very concerned about the "WHY DNS MATTERS FOR SYSTEM DESIGN" section. While everything there is correct enough, it doesn't dive into the implication of each and how things go wrong.

There is a reason we say "it's always DNS".

Curious how you’d measure this

ISP DNS servers really ought to be banned, they are always so bad. I've seen traffic days later on a record with 1 hour TTL. In general I see like 50% traffic move after the initial 1-2x TTL interval, another 40-45% over next several hours up to one day, and then the last 5-1% can take forever.

For round-robin, I've actually had it work reasonably well for API usage. Of course it's not ideal, but when I wanted to roll out new things slowly over several days and could not use a load balancer or reverse proxy, it kind of worked. I think most API users are just running with a reasonable resolver and not residential ISP ones.

> It's the people who think they are clever and try to make things better by making them worse.

you mean DNSSEC, right? RIGHT?

You'd still need to memorize the IP address without DNS, otherwise how would you know to which server to connect?

The fact that a server can serve multiple vhosts and do TLS cert selection via SNI is not related to the lookup of what server to connect to.

Curious how you’d measure this

When I moved reddit from one datacenter to another, about 70% of the traffic shifted within the TTL. Another 20% moved within a week. Took till the end of a month after the change to get to about 98%

But after two months, about 1% was still going to the old server (I had set it up as a proxy for the cutover). Most of that traffic looked like crawlers that were written in things like Python or Ruby and had probably hard coded the IP or done something where it just didn't know what a TTL was.

So at that point I just shut down the old server.

You're probably right about API clients using better resolvers though. I was talking about consumer facing things where a lot of people would be on ISP DNS.

> It's the people who think they are clever and try to make things better by making them worse.

you mean DNSSEC, right? RIGHT?

When I moved reddit from one datacenter to another, about 70% of the traffic shifted within the TTL. Another 20% moved within a week. Took till the end of a month after the change to get to about 98%

So at that point I just shut down the old server.

You're probably right about API clients using better resolvers though. I was talking about consumer facing things where a lot of people would be on ISP DNS.

Last week, I pointed my domain to a new server. Changed the A record, waited... nothing. The old site kept showing up. I cleared my browser cache. Still nothing. Restarted my computer. Nothing.

Three hours later, I learned about DNS propagation and TTL. That rabbit hole led me to actually understand how DNS works. Not just "it translates domains to IPs" - but the whole system.

Here's what I learned.

At its core, DNS is simple: it translates domain names into IP addresses. You type example.com, DNS returns 93.184.216.34, and your browser connects to that IP. Without DNS, you'd need to memorize IP addresses for every website. Nobody wants that.

But the how is where it gets interesting.

DNS Hierarchy

Here's the mental model that finally made DNS click for me: it's organized like a chain of referrals. Each level knows about the level below it, and nobody knows everything.

DNS Hierarchy diagram showing Root, TLDs, Domains, and Subdomains

Root (.)

Every DNS lookup starts here. I didn't even know root servers existed until I had to debug my propagation issue. There are 13 root server clusters worldwide, operated by organizations like Verisign, ICANN, and NASA. Root servers don't know where example.com is - but they know where to find the .com TLD servers. They're the starting point of the referral chain.

TLD (Top Level Domain)

You know this part - the last bit of a domain: .com, .org, .in, .io. TLD servers know all domains registered under them. The .com TLD knows where to find example.com, google.com, and every other .com domain.

Common TLDs:

.com - Commercial (anyone can register)
.org - Organizations
.net - Network services
.io - British Indian Ocean Territory (popular with tech)
.dev - Developers (requires HTTPS)
.gov - US Government only
.edu - Educational institutions

Domain

The name you actually buy: example, google, github. Combined with TLD, you get example.com. This is what you purchase from registrars like Namecheap, GoDaddy, or Cloudflare. I use Cloudflare for my domains - the DNS management is clean and free. (Once you understand DNS, you might want to check out my guide on deploying Django REST Framework to production - that's where you'll actually use this knowledge.)

Subdomain

Anything before the domain: api.example.com, mail.example.com, staging.example.com. The cool part? You create these yourself through DNS records. No additional purchase needed. If you own example.com, you can create unlimited subdomains for free.

DNS Records

When I first opened my domain's DNS panel, I saw a bunch of record types I didn't understand. A, AAAA, CNAME, MX, TXT... it looked intimidating. But once you know what each one does, it's actually straightforward.

A Record

This is the one you'll use most. Maps a domain to an IPv4 address. When I moved my site to a new server, this is what I changed.

example.com    A    93.184.216.34

When someone requests example.com, DNS returns 93.184.216.34.

AAAA Record

Same thing, but for IPv6 addresses. The weird name? Four A's because IPv6 addresses are four times longer than IPv4. I haven't had to set one of these up myself yet.

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

CNAME (Canonical Name)

This one's clever. Instead of pointing to an IP, it points to another domain. It says "go ask this other domain instead."

www.example.com     CNAME    example.com
blog.example.com    CNAME    example.ghost.io

Super useful when you use third-party services. I use this to point subdomains to hosted services - your blog can point to Ghost, your docs to GitBook, without managing their IPs yourself.

MX (Mail Exchange)

Ever wondered how [[email protected]](https://www.bhusalmanish.com.np/cdn-cgi/l/email-protection) knows where to go? MX records. They specify where to deliver emails for your domain. The priority number matters - lower numbers are tried first.

example.com    MX    10    mail1.example.com
example.com    MX    20    mail2.example.com

When someone emails [[email protected]](https://www.bhusalmanish.com.np/cdn-cgi/l/email-protection), mail servers check the MX record to find where to deliver. If mail1 (priority 10) is down, it tries mail2 (priority 20).

TXT Record

This one seems random at first - it just stores text. But it's used for some important stuff.

example.com    TXT    "v=spf1 include:_spf.google.com ~all"
example.com    TXT    "google-site-verification=abc123xyz"

I've used TXT records for:

Domain verification - Google, Stripe, AWS ask you to add a TXT record to prove you own the domain
SPF - Specifies which servers can send email on your behalf (prevents spoofing)
DKIM - Email authentication using cryptographic signatures
DMARC - Policy for handling failed SPF/DKIM checks

TTL (Time To Live)

This is what got me. Remember my three hours of confusion? The TTL on my old A record was 3600 seconds. That's one hour. Every resolver that had cached my old IP would hold onto it for up to an hour before checking again.

TTL tells resolvers how long to cache a DNS result.

example.com    A    93.184.216.34    TTL=3600

This means: "Cache this answer for 3600 seconds (1 hour). Don't ask again until then."

Common TTL values:

300 (5 min) - Frequent changes, quick failover needed
3600 (1 hour) - Normal websites
86400 (1 day) - Rarely changes

The Trade-off

Low TTL = Faster updates, but more DNS queries (slightly slower first load).

High TTL = Fewer DNS queries (better performance), but slower propagation when you change records.

Pro tip I learned the hard way: if you're planning to migrate servers, lower your TTL to 300 a few days before. After migration, old cached records expire in 5 minutes instead of hours. Wish I'd known this before my migration.

DNS Resolution Process

Once I traced through this whole process, everything clicked. Here's what actually happens when you type api.example.com in your browser:

Step 1: Browser cache
"Do I have api.example.com cached?" → No

Step 2: OS DNS cache
"Do I have it?" → No

Step 3: Router cache
"Do I have it?" → No

Step 4: ISP's DNS Resolver
"Do I have it?" → No, let me find out...

Step 5: Ask Root Server
Resolver: "Where is api.example.com?"
Root: "I don't know, but .com TLD is at 192.5.6.30"

Step 6: Ask .com TLD Server
Resolver: "Where is api.example.com?"
TLD: "I don't know, but example.com's nameserver is at ns1.example.com"

Step 7: Ask example.com's Nameserver
Resolver: "Where is api.example.com?"
NS: "It's at 93.184.216.34"

Step 8: Response flows back
Resolver caches it (based on TTL)
Returns 93.184.216.34 to your browser

Step 9: Browser connects to 93.184.216.34

Visual representation:

DNS Resolution Process diagram showing the flow from browser through caches to nameserver

Each intermediate resolver caches the result based on TTL. Subsequent requests from the same network skip most of this because the resolver already knows the answer. That's why the second visit to a site is faster than the first.

What is a Resolver?

I used to confuse resolvers and nameservers. They sound similar, but they do different jobs.

A resolver is a DNS server that does the hard work of finding IP addresses for you. It handles the recursive lookup through Root → TLD → Authoritative nameservers.

Your device asks a resolver: "What's the IP of example.com?" The resolver does all the work and returns: "It's 93.184.216.34"

Common public resolvers:

8.8.8.8 - Google Public DNS
1.1.1.1 - Cloudflare (fastest, privacy-focused)
208.67.222.222 - OpenDNS (Cisco)
9.9.9.9 - Quad9 (security-focused, blocks malware)

You can change which resolver you use in your network settings. I switched to 1.1.1.1 on my machines - it's noticeably faster than my ISP's default resolver.

What is a Nameserver?

A nameserver is the source of truth. It actually holds the DNS records for a domain. When you register a domain, you point it to nameservers that store your A records, CNAME records, MX records, etc.

The difference between resolvers and nameservers:

Resolver - Finds answers by asking other servers (the messenger)
Nameserver - Holds the actual DNS records (the source of truth)

When you buy a domain from Namecheap or GoDaddy, they give you default nameservers like:

ns1.namecheap.com
ns2.namecheap.com

You can change these to use Cloudflare, AWS Route 53, or your own nameservers:

# Cloudflare nameservers
ns1.cloudflare.com
ns2.cloudflare.com

# AWS Route 53 (example)
ns-1234.awsdns-56.org
ns-789.awsdns-12.co.uk

Why bother changing nameservers? Different providers offer different features. I moved my domains to Cloudflare because they give you free DDoS protection, a CDN, and the dashboard is just nicer to use. Route 53 makes sense if you're already deep in AWS.

Authoritative vs Recursive

Authoritative nameserver - Has the final answer for a domain. When asked "Where is example.com?", it responds with the actual IP because it holds the records.

Recursive resolver - Doesn't hold records, but finds answers by asking authoritative servers. Your ISP's DNS server and 8.8.8.8 are recursive resolvers.

View DNS Cache

These commands saved me during my debugging session. When you need to see what's actually cached:

In Browser

# Chrome
chrome://net-internals/#dns

# Firefox
about:networking#dns

# Edge
edge://net-internals/#dns

These show all cached domains with their IPs and remaining TTL.

On Your Computer

# Windows (Command Prompt)
ipconfig /displaydns

# Mac
sudo dscacheutil -cachedump

# Linux
# Most distros use systemd-resolved
resolvectl statistics

Query a Domain

# Using nslookup (Windows/Mac/Linux)
nslookup example.com

# Using dig (Mac/Linux - more detailed)
dig example.com

# Query specific record type
dig example.com MX
dig example.com TXT

# Query using a specific resolver
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

Clear DNS Cache

Browser

Go to chrome://net-internals/#dns and click "Clear host cache".

Operating System

# Windows
ipconfig /flushdns

# Mac
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd)
sudo systemd-resolve --flush-caches

This is what I should've done first. Flushing the cache forces your system to fetch fresh DNS records instead of using stale cached ones.

Why DNS Matters for System Design

Here's where DNS gets interesting beyond just "hosting a website." If you're designing systems at scale, DNS becomes a tool, not just a lookup service.

Load Distribution

DNS can return different IPs for the same domain. Each request might get a different server. This is called DNS round-robin load balancing.

example.com    A    93.184.216.34
example.com    A    93.184.216.35
example.com    A    93.184.216.36

Failover

If one server dies, DNS can stop returning its IP. Health checks detect the failure, DNS record is updated, traffic flows to healthy servers.

Geographic Routing

Return IPs of servers closest to the user. A user in Europe gets European server IPs, a user in Asia gets Asian server IPs. This is called GeoDNS or latency-based routing.

Caching Trade-offs

DNS caching reduces lookup time and load on DNS servers. But it makes instant updates impossible. If you change an IP and TTL is 24 hours, some users will hit the old IP for up to 24 hours.

Quick Reference

┌─────────────┬────────────────────────────────────────┐
│ Term        │ What it does                           │
├─────────────┼────────────────────────────────────────┤
│ Root        │ Top of DNS tree, knows TLD locations   │
│ TLD         │ .com, .org, .io - knows domains under  │
│ Domain      │ What you buy (example, google)         │
│ Subdomain   │ What you create free (api, www, mail)  │
├─────────────┼────────────────────────────────────────┤
│ A Record    │ Domain → IPv4 address                  │
│ AAAA Record │ Domain → IPv6 address                  │
│ CNAME       │ Domain → Another domain (alias)        │
│ MX          │ Where to send email                    │
│ TXT         │ Verification, SPF, DKIM, DMARC         │
├─────────────┼────────────────────────────────────────┤
│ TTL         │ Cache duration in seconds              │
│ Resolver    │ Server that finds IPs for you          │
└─────────────┴────────────────────────────────────────┘

DNS broke my site for three hours. But now I actually understand it - not just what it does, but how it works. Next time something doesn't propagate, I'll know exactly where to look.

What's something you use every day but never really understood until it broke?

Manish Bhusal

Software Developer from Nepal. 3x Hackathon Winner. Building digital products and learning in public.

Hacker Times