What Happens When You Type google.com? (DNS Explained Simply)

Search for a command to run...

dns is basically invisible until something goes wrong and then it feels like the whole app is broken even if nothing changed on your side
Nice explanation! DNS is one of those concepts that's easy to take for granted until you understand how much happens before a single webpage loads.
I especially liked the emphasis on caching. Many developers focus on the resolution process itself, but browser, OS, resolver, and CDN caching play a huge role in reducing latency and improving user experience. Understanding these fundamentals makes topics like load balancing, CDNs, and distributed system design much easier to grasp later on.
Looking forward to the next article in the series!
Appreciate it! Glad you found it useful.
Great breakdown of how DNS resolution works. One thing worth adding once you understand this flow is the ability to query DNS records programmatically. WhoisFreaks has a DNS Lookup API that lets you fetch A, MX, NS, TXT and other record types for any domain. Useful when you are building tools that need to verify domain configuration, debug DNS propagation issues, or monitor DNS changes over time. Fits naturally into the system design and troubleshooting use cases you mentioned at the end.
When building traditional software, engineers write tests to make sure code works correctly. Every time you change a feature or update a package, automated tests run to catch bugs before they reach re

When you first start building applications, you usually think about buying or renting a server—a computer that sits somewhere in a data center, running 24/7, waiting for someone to use their app. But

You've built your application. Now, it's time to deploy it to Amazon Web Services (AWS). So, you open the AWS Console, click through a dozen complex menus, create an Amazon S3 bucket, wire up an AWS L

Your application is running on multiple servers. Traffic is growing. Everything looks good — until one day, your database becomes the slowest part of the system.

When you launch a new application, a single-server architecture is usually more than enough. Your users send requests, the server processes the backend logic, talks to the database, and returns a resp

Most engineers use the internet every day without thinking about what actually happens before a page loads.
Understanding that process is one of the first building blocks of system design.
Let's start with a simple question: what happens when you type google.com into your browser?
Computers communicate using IP addresses, not domain names.
For example:
142.250.190.78
An IP address is like a street address. It tells the internet exactly where a server lives.
The problem is obvious. Remembering google.com is easy. Remembering 142.250.190.78 is not.
That's why domain names exist.
DNS stands for Domain Name System.
Think of it as the internet's phonebook.
You provide a name:
google.com
DNS returns an address:
142.250.xxx.xxx
Without DNS, every website would need to be accessed by its raw IP address. The modern internet would be unusable.
When you type google.com, your browser first checks:
"Do I already know the IP address for this?"
If not, it starts a DNS lookup:
Browser
↓
DNS Resolver (usually your ISP)
↓
Root Name Server
↓
TLD Name Server (.com)
↓
Authoritative Name Server (google.com)
↓
IP Address returned to browser
Once the browser has the IP address, it knows exactly where to send the request.
This entire process typically completes in milliseconds.
Every DNS lookup takes time. If your browser had to repeat this process on every request, the internet would feel noticeably slower.
To solve this, DNS responses are cached at multiple levels:
Browser cache — your browser stores recent lookups
Operating system cache — your OS keeps its own DNS records
ISP cache — your internet provider caches lookups across all its users
When your browser already knows google.com → 142.250.xxx.xxx, it skips the lookup entirely.
This is why websites often load faster on the second visit.
Most engineers never think about DNS until something breaks.
But DNS sits at the very beginning of every request your users make. Understanding it helps you reason about:
Why a website becomes unreachable even when your server is running fine
Why DNS outages can take down entire companies
Why latency exists before a request even reaches your application
How traffic gets routed to the correct server across the globe
DNS is also the foundation for more advanced concepts like load balancing, failover, and CDN routing.
Before any of that complexity kicks in, a simple lookup has already happened. Silently. In milliseconds. Every single time.