Every website visit starts with a question
When you open your browser and type:
https://themissinglevel.devA few moments later, the website appears.
It feels almost instant, but your browser couldn't possibly know where to find the website on its own. The internet doesn't route traffic using names like themissinglevel.dev. It routes traffic using IP addresses such as 203.0.113.42 or IPv6 addresses like 2001:db8::42.
Without first finding that IP address through a DNS lookup, your browser wouldn't know where to send the request.
So before anything else can happen, your browser has to answer a simple question:
Which computer should I connect to?
Think of it like calling someone on your phone. You tap a contact named Joe instead of memorizing a phone number. Before the call can be placed, your phone looks up the number associated with that contact.
Your browser works in much the same way. Before it can connect to a website, it performs a DNS lookup to find the IP address associated with the domain.
You type a domain
themissinglevel.dev
↓
DNS finds the IP
↓
203.0.113.42
↓
Browser sends the request to that IPWithout DNS, the browser wouldn't know where to connect, so the request could never reach the website.
Now let's see what actually happens when your browser looks up a domain name.
What exactly is DNS?
Although DNS (Domain Name System) often feels like a single service, it isn't. It's a distributed system made up of thousands of DNS servers around the world. Each DNS server is responsible for only a small part of the internet's namespace, and together they can resolve millions of domain names.
This distributed design makes DNS scalable, resilient, and fast. If every domain on the internet had to be stored in one central database, the system would quickly become impossible to manage. Instead, responsibility is shared across many DNS servers. Each one manages a different part of the DNS hierarchy and works together with the others to answer queries.
Because each server only manages a small part of the internet's namespace, DNS can continue to grow without relying on one massive central database.
How a DNS lookup works, step by step
Although a DNS lookup can involve several servers across the internet, the browser always starts with the fastest option: checking whether it already knows the answer.
Step 1: The browser checks its DNS cache
The browser's first question isn't "Which DNS server should I contact?"
It's:
"Have I looked up this domain recently?"
Modern web browsers maintain a small DNS cache in memory to speed up future DNS lookups. If you've recently visited the same website, the browser may already have the corresponding IP address stored locally.
For example, if you visited themissinglevel.dev a few minutes ago, the browser might already know that it resolves to 203.0.113.42.
In that case, there's no need to perform another DNS lookup. The browser can immediately begin establishing a connection with the server, making the page load a little faster and avoiding unnecessary network traffic.
User enters
themissinglevel.dev
↓
┌─────────────────────┐
│ Browser DNS Cache │
└─────────────────────┘
│ │
Hit Miss
│ │
↓ ↓
Use Check OS
cached IP DNS Cache Cache hit: The requested data is found in the cache.
Cache miss: The requested data isn't in the cache, so the system has to look elsewhere.
If the browser doesn't have a cached entry, or if the cached entry has expired, it asks the operating system to continue the search.
Step 2: The operating system checks its DNS cache
Like the browser, modern operating systems maintain their own DNS cache. Unlike the browser's cache, however, the operating system's cache is shared across applications. This means that if another browser or application (e.g. curl) recently looked up the same domain, the IP address may already be stored in the operating system's cache.
If a valid cached entry exists, the operating system returns the IP address to the browser, which can immediately begin establishing a connection.
If not, the operating system forwards the DNS query to its configured recursive DNS resolver.
Step 3: The request reaches a recursive DNS resolver
The operating system sends the DNS query to a recursive DNS resolver. This is a remote server operated by your internet service provider (ISP), your organization, or a public DNS provider.
It's called recursive because it takes responsibility for finding the complete answer on your behalf. Instead of simply pointing to another DNS server, it continues querying other DNS servers until it either finds the IP address or determines that the domain doesn't exist.
Your Computer
|
| DNS query
↓
+-------------------------------+
| Recursive DNS Resolver |
+-------------------------------+
|
"I'll continue searching
until I find the answer."
|
↓
Other DNS servers...
|
↓
Final IP address
|
↓
Your ComputerBefore contacting other DNS servers, the resolver first checks its own cache. If another user recently requested the same domain and the cached record is still valid, it can immediately return the IP address to your computer.
If the answer isn't cached, the resolver begins following the DNS hierarchy. Rather than contacting DNS servers at random, it queries them in a specific order:
- Ask a root nameserver which top-level domain (TLD) nameserver to contact.
- Ask the TLD nameserver which authoritative nameserver to contact.
- Ask the authoritative nameserver for the domain's IP address.
Don't worry if some of these terms are unfamiliar. We'll explain what each server does and walk through every step in the following sections.
Step 4: The resolver asks a root nameserver
If the recursive DNS resolver can't find the answer in its cache, it begins searching the DNS hierarchy.
The first stop is a root nameserver. A root nameserver is a special DNS server at the very top of the DNS hierarchy. Rather than storing the IP addresses of individual websites, it acts like a directory, knowing which nameservers are responsible for each top-level domain (TLD), such as .com, .dev, .org, and .net.
Root Nameserver
"Who manages each TLD?"
┌─────────────────┼─────────────────┐
↓ ↓ ↓
+---------+ +---------+ +---------+
| .com | | .org | | .dev |
| TLD | | TLD | | TLD |
| Server | | Server | | Server |
+---------+ +---------+ +---------+So the resolver asks:
"Where can I find information about
themissinglevel.dev?"
The root nameserver doesn't return an IP address. Instead, it replies with the addresses of the nameservers responsible for the .dev top-level domain.
Resolver Root Nameserver
| |
| Where can I find |
| themissinglevel.dev? |
|──────────────────────────>|
| |
| "I don't know, but ask |
| one of the .dev |
| nameservers." |
|<──────────────────────────|Step 5: The resolver asks a TLD nameserver
Using the information returned by the root nameserver, the resolver contacts one of the .dev TLD nameservers.
A top-level domain (TLD) nameserver knows which authoritative nameserver is responsible for every domain registered under its TLD. It doesn't know the domain's IP address, but it knows where to find the server that does.
The resolver asks:
"Who is responsible for
themissinglevel.dev?"
The TLD nameserver replies with the address of the domain's authoritative nameserver.
Resolver .dev TLD Nameserver
| |
| Where can I find |
| themissinglevel.dev? |
|──────────────────────────>|
| |
| "Ask this authoritative |
| nameserver." |
| Authoritative Nameserver |
|<──────────────────────────|
Authoritative Nameserver
Step 6: The resolver asks the authoritative nameserver
Using the information returned by the TLD nameserver, the resolver contacts the authoritative nameserver for themissinglevel.dev.
An authoritative nameserver stores the official DNS records for a domain and provides the authoritative answer during a DNS lookup. Unlike the root and TLD nameservers, it has the final answer.
The resolver asks:
"What is the IP address of
themissinglevel.dev?"
The authoritative nameserver looks up the requested DNS record and replies:
themissinglevel.dev → 203.0.113.42The resolver now has the answer it was looking for. Before returning it to your computer, it usually stores the result in its cache for a period of time so future requests for the same domain can be answered much faster.
Finally, the resolver returns the IP address to your operating system, which then passes it to the browser.
Resolver
|
"What's the IP address of
themissinglevel.dev?"
|
↓
+--------------------------+
| Authoritative Nameserver |
+--------------------------+
|
| 203.0.113.42
↓
ResolverStep 7: The browser can finally connect to the server
At this point, DNS has finished its job.
The browser now knows the website's IP address, so it can begin establishing a connection.
This typically involves:
- Opening a TCP connection.
- Performing a TLS handshake if the site uses HTTPS.
- Sending the first HTTP request.
That first HTTP request also includes request headers, which tell the server things like which content types the browser accepts, whether it already has cached resources, and much more. If you're curious about what those headers do and which ones you'll encounter most often, check out 7 HTTP request headers every developer should understand.
Once the server receives the request, it can start sending back the HTML, images, CSS, JavaScript, and everything else needed to display the page.
DNS doesn't download websites—it simply tells your browser where to find them.
If you'd like to follow what happens next, from the TCP connection and TLS handshake all the way to HTML parsing and rendering the first pixel on screen, continue with What happens after you press Enter.
What happens if DNS can't find the domain?
Sometimes a DNS lookup fails because the requested domain or DNS record can't be found.
If the authoritative nameserver doesn't contain the requested domain or record, it returns a response indicating that the domain doesn't exist (commonly called NXDOMAIN, short for Non-Existent Domain).
When that happens, the resolver has nowhere else to look, so it returns the failure to your computer.
Your browser then displays an error such as:
- "This site can't be reached"
- "Server not found"
- "DNS_PROBE_FINISHED_NXDOMAIN"
In many cases, the problem isn't that the website is offline. The domain simply couldn't be resolved to an IP address.
A real DNS lookup example
You can perform your own DNS lookup from the command line using the dig (Domain Information Groper) command. It's a command-line tool for querying DNS servers and is commonly available on Linux and macOS. Windows users can install it through tools such as BIND or use the built-in nslookup command instead.
dig themissinglevel.devAmong the output, you'll see an ANSWER SECTION similar to this:
;; ANSWER SECTION:
themissinglevel.dev. 300 IN A 104.21.14.102
themissinglevel.dev. 300 IN A 172.67.158.160Breaking this down:
-
themissinglevel.dev— the domain name that was queried. -
300— the TTL (Time To Live), measured in seconds. It tells DNS resolvers how long they can cache this answer before asking again. In this example, the result can be cached for 5 minutes. -
IN— indicates that this record belongs to the Internet. You'll seeINin almost every DNS lookup. -
A— the DNS record type. An A record maps a domain name to an IPv4 address. (For IPv6 addresses, DNS uses an AAAA record instead.) -
104.21.14.102and172.67.158.160— the IPv4 addresses returned for the domain. Notice that there are two A records. This is common for websites that use multiple servers or a CDN, allowing traffic to be distributed across different IP addresses for better performance and reliability.
Common misconceptions about DNS
DNS and HTTP are not the same thing
DNS happens before HTTP.
DNS finds the server's IP address. HTTP is then used to request pages and other resources from that server.
DNS doesn't know what page you're visiting
DNS only resolves the domain name.
Whether you visit:
example.comexample.com/aboutexample.com/blog/article
the DNS lookup is exactly the same because the domain hasn't changed.
DNS isn't one giant database
DNS is a distributed system made up of thousands of servers around the world.
Each server is responsible for only a small part of the overall hierarchy.
A real-world scenario
Imagine you've just deployed a new website to a VPS with the IP address 203.0.113.42.
If you're setting up a brand-new domain, it's also worth checking whether it has been used before. A domain's previous history can affect SEO, email deliverability, and even browser trust. I explain why in Why you should check a domain's history before buying it.
To make mywebsite.com point to your server, you log in to your DNS provider (such as Cloudflare) and create an A record:
Type: A
Name: @
Value: 203.0.113.42When someone later visits https://mywebsite.com, their browser performs a DNS lookup, resolves the domain name to 203.0.113.42, and then connects to your server.
Without that DNS record, browsers wouldn't know where your website is hosted.
Remember the DNS caches from earlier? Even if your new DNS record has propagated successfully, your browser, operating system, or DNS resolver may still have the previous result cached. If that happens, you might not see your website immediately. Waiting for the cache to expire—or clearing your local DNS cache—usually resolves the issue.
Frequently asked questions
Can one domain have multiple IP addresses?
Yes.
A domain can have multiple A records (which map a domain to IPv4 addresses) or multiple AAAA records (which map a domain to IPv6 addresses).
In many cases, each IP address belongs to a different server. When someone visits the domain, DNS can return multiple IP addresses, allowing requests to be distributed across those servers. This helps with load balancing, redundancy, and improving availability.
For example:
example.com. A 192.0.2.10
example.com. A 192.0.2.11When a DNS resolver looks up example.com, it may receive both IP addresses and connect to one of them.
Is DNS secure during a DNS lookup?
By default, DNS queries are sent without encryption, which means other systems on the network may be able to observe which domains you're looking up.
Technologies such as DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS queries while they're being transmitted, making them much harder to intercept.
However, encryption only protects the communication between your device and the DNS resolver. It doesn't guarantee that the DNS response itself is genuine.
That's where DNSSEC (Domain Name System Security Extensions) comes in. DNSSEC adds digital signatures to DNS records, allowing resolvers to verify that the response really came from the domain's authoritative nameserver and wasn't altered or forged along the way.
Without DNSSEC, an attacker could potentially forge a DNS response and redirect users to the wrong server.
Before you go
Here are a few practical things worth remembering the next time you're working with domains or debugging network issues:
- Not every connection problem is a server problem. If a domain can't be resolved, the browser never reaches your server.
- DNS changes aren't always visible immediately. Before assuming propagation is still in progress, remember that your browser, operating system, or DNS resolver may have cached the previous result. You may need to wait for the cache to expire or clear your local DNS cache.
- One domain can point to multiple IP addresses. This is commonly used for load balancing, redundancy, and CDNs.
- Keep
digin your toolbox. It's one of the quickest ways to verify DNS records and troubleshoot domain-related issues.