DNS Resolution

What actually happens between typing a URL and seeing a webpage.

Introduction

Every time you visit a website, your computer needs to find the server responsible for a domain name such as google.com.

Humans prefer names:

google.com

Computers ultimately communicate with network addresses such as:

142.250.190.14

DNS (Domain Name System) is the system that connects these two worlds.

Think of DNS as the phonebook of the internet:

You know someone's name. DNS helps you find their number.

Understanding DNS is useful for developers because it explains:

• Why a website sometimes doesn't load
• Why DNS changes aren't immediate
• How domains point to servers and CDNs
• Why localhost and /etc/hosts are useful
• What happens before an HTTP request ever reaches your server

The Big Picture

When you enter:

https://google.com

a simplified version of what happens is:

You enter google.com
        │
        ▼
 Browser / OS checks local information
        │
        │ cache miss
        ▼
 Recursive DNS Resolver
        │
        │ needs to find the answer
        ▼
   DNS hierarchy
        │
        ├── Root DNS
        │
        ├── .com TLD DNS
        │
        └── Google's Authoritative DNS
                    │
                    ▼
              DNS record
                    │
                    ▼
          Recursive Resolver
                    │
                    ▼
             Your computer
                    │
                    ▼
          Connect to the server
                    │
             ┌──────┴──────┐
             ▼             ▼
            TCP           TLS
             │             │
             └──────┬──────┘
                    ▼
              HTTP request
                    │
                    ▼
                 Server
                    │
                    ▼
              HTTP response
                    │
                    ▼
             Browser renders

But there's an important detail:

The entire Root → TLD → Authoritative journey does NOT happen every time.

DNS is heavily cached.

If a recursive resolver already knows the answer, it can return it immediately without contacting the root or TLD servers.

First: What Is a DNS Resolver?

Before looking at the lookup process, we need to understand an important distinction.

There are two major types of DNS servers involved:

Recursive Resolver

A recursive resolver is the server you normally ask:

"Find me the DNS information for google.com."

Examples include:

Google DNS       → 8.8.8.8
Cloudflare DNS   → 1.1.1.1
Your ISP's DNS   → ISP-provided resolver

The resolver does the work of finding the answer if it doesn't already have it cached.

Think:

Your computer:
"What's the IP of google.com?"
 
Resolver:
"I'll find out."

Authoritative DNS Server

An authoritative DNS server is responsible for the DNS records of a particular domain/zone.

Think:

Resolver:
"What does google.com resolve to?"
 
Authoritative DNS:
"Here are the DNS records I'm authoritative for."

The authoritative server is the source of authority for that DNS zone.

A useful shorthand: the recursive resolver is the librarian who goes and finds the book for you; the authoritative server is the publisher who actually wrote it.

Step 1: Browser and Local Caches

When you visit a domain, your system may already know the answer.

Browsers and operating systems can cache DNS information.

Conceptually:

Do I already know google.com?
        │
       YES
        │
        ▼
Use the cached information

If the information isn't available locally, the system needs to ask a DNS resolver.

The exact order and caching behavior can vary between browsers, operating systems, and configurations, so don't think of this as a universal fixed sequence.

Step 2: The Hosts File

Your operating system can also use a local hosts file to manually map names to IP addresses.

Common locations are:

For example:

127.0.0.1   myapp.local

Now your machine can resolve:

myapp.local

to:

127.0.0.1

without needing a public DNS record.

This is why developers use it constantly: testing a domain before DNS is configured, running multiple local apps under fake hostnames, or temporarily overriding resolution to block or redirect a domain.

Step 3: Ask the Recursive DNS Resolver

If your local system doesn't already have the answer, it asks a recursive DNS resolver.

For example:

Your computer
      │
      │ "What's the IP of google.com?"
      ▼
8.8.8.8

The resolver now has two possibilities.

Case 1: Resolver has the answer cached

Computer
   │
   ▼
Resolver
   │
   │ cache hit
   ▼
IP address

Done. No root server is required.

Case 2: Resolver doesn't have the answer

The resolver needs to find it.

That's when the DNS hierarchy becomes important.

Step 4: Root DNS Servers

The DNS hierarchy starts at the root.

There are 13 logical root server identities, operated by different organizations. Each identity is served from many physical locations around the world using anycast.

The resolver asks something conceptually like:

"Who handles .com domains?"

The root server doesn't know the IP address of google.com.

Instead, it knows where the .com TLD servers are.

It responds with information pointing toward the .com nameservers.

Recursive Resolver
        │
        │ Who handles .com?
        ▼
     Root DNS
        │
        │ Ask the .com TLD servers
        ▼
     .com TLD

Step 5: The TLD Server

TLD means Top-Level Domain.

Examples:

.com
.org
.net
.dev
.bd

The resolver now asks a .com TLD server:

"Who is authoritative for google.com?"

Again, the TLD server doesn't necessarily provide Google's final IP address.

Instead, it provides information about the authoritative nameservers for google.com.

Conceptually:

Recursive Resolver
        │
        │ Who handles google.com?
        ▼
    .com TLD
        │
        │ Ask Google's authoritative DNS
        ▼
Authoritative DNS

Step 6: Authoritative DNS Server

Now the resolver reaches a DNS server that is authoritative for Google's DNS zone.

It asks:

"What DNS record exists for google.com?"

The authoritative server provides the appropriate DNS record.

For an IPv4 address, this is an:

A record

For IPv6, it's:

AAAA record

For example:

google.com
     │
     └── A → 142.250.x.x

The actual addresses returned can vary.

Also, DNS doesn't necessarily return a single IP.

A domain can have multiple records:

google.com
     │
     ├── A → 142.250.1.10
     ├── A → 142.250.1.20
     └── A → 142.250.1.30

This can be used for things such as load distribution and redundancy.

A More Realistic DNS Lookup

Putting everything together:

Your Computer
      │
      │ DNS query
      ▼
Recursive Resolver
      │
      │ cache miss
      ▼
   Root DNS
      │
      │ .com nameservers
      ▼
   .com TLD
      │
      │ authoritative nameservers
      ▼
Authoritative DNS
      │
      │ A / AAAA / CNAME / etc.
      ▼
Recursive Resolver
      │
      │ caches result
      ▼
Your Computer

Remember:

This is what happens when the resolver needs to discover the answer.

If the resolver already has the answer cached, the process can be much shorter:

Your Computer
      │
      ▼
Recursive Resolver
      │
      │ cache hit
      ▼
IP address

Step 7: DNS Caching and TTL

DNS would be extremely inefficient if every request had to travel through the hierarchy.

That's why DNS relies heavily on caching.

DNS records have a value called:

TTL — Time To Live

For example:

google.com
A
142.250.x.x
TTL: 300

A TTL of:

300 seconds

means a resolver can generally cache that record for about:

5 minutes

During that period, the resolver can answer from its cache instead of asking the authoritative server again.

Why TTL Matters

Suppose your domain currently points to:

example.com → 10.0.0.1

You change it to:

example.com → 20.0.0.1

Some DNS resolvers may still have the old answer cached.

So users might temporarily receive:

10.0.0.1

while others receive:

20.0.0.1

This is one reason DNS changes aren't necessarily visible everywhere immediately.

Important developer lesson

Before a planned DNS migration, you can often lower the TTL ahead of time.

For example:

1 day
 ↓
1 hour
 ↓
5 minutes

Then make the DNS change.

Existing cached records can expire sooner.

Step 8: DNS Records Aren't Always IP Addresses

A common beginner misconception is:

"DNS converts a domain directly into an IP."

That's often true for an A or AAAA lookup, but DNS supports many record types.

A

Maps a name to an IPv4 address:

example.com → 192.0.2.10

AAAA

Maps a name to an IPv6 address:

example.com → 2001:db8::10

CNAME

Creates an alias to another domain name:

www.example.com
        │
        ▼
example.com

The resolver may then need to resolve the target name as well.

MX

Specifies mail servers:

example.com → mail.example.com

TXT

Stores arbitrary text attached to a domain. It's a bit of a catch-all record type — anything that doesn't fit neatly into A, CNAME, or MX often ends up here. Common uses:

• Domain verification — proving you own a domain (e.g. "add this TXT record to verify your site with Google Search Console")
• Email authentication — SPF and DKIM records tell other mail servers which senders are allowed to send email on your domain's behalf, which helps prevent spoofing and keeps your email out of spam folders
• General metadata — anything else a service wants to attach to a domain without needing its own record type

NS

Specifies authoritative nameservers for a DNS zone.

Step 9: DNS Resolution Is Finished

Once your computer receives the necessary DNS information:

google.com
      ↓
IP address

DNS's job is essentially finished.

Now the browser needs to connect to that IP address.

This is where networking protocols take over.

Step 10: Establishing the Connection

Suppose DNS returned:

142.250.x.x

The browser can now connect to the server.

For HTTPS, the traditional conceptual sequence is:

DNS
 ↓
TCP connection
 ↓
TLS handshake
 ↓
HTTP request
 ↓
HTTP response

10.1 TCP Connection

For HTTP/1.1 and HTTP/2 over TCP, the browser establishes a TCP connection.

The classic TCP three-way handshake is:

Client                    Server
 
  SYN ──────────────────►
 
      ◄──────────────── SYN-ACK
 
  ACK ──────────────────►

Now the TCP connection is established.

HTTPS commonly uses:

TCP port 443

Step 11: TLS Handshake

Because the URL uses:

https://

the connection needs encryption and authentication.

The browser and server perform a TLS handshake.

Among other things, they:

• Negotiate cryptographic parameters
• Establish shared session keys
• Authenticate the server using its certificate

The certificate is checked against trusted Certificate Authorities and the requested hostname.

Conceptually:

Browser
   │
   │ TLS handshake
   ▼
Server
   │
   │ Certificate + key agreement
   ▼
Encrypted connection

Now the browser can securely communicate with the server.

Step 12: HTTP Request

The browser can finally send an HTTP request.

For example:

GET / HTTP/1.1
Host: google.com

The actual protocol may instead be HTTP/2 or HTTP/3 depending on what the client and server support.

The important idea is:

DNS

helped find where to connect.

Then:

HTTP

defines what you want from the server.

Step 13: Server Responds

The server processes the request and sends a response.

For example:

HTTP/1.1 200 OK
Content-Type: text/html

followed by HTML.

The browser then discovers additional resources such as:

CSS
JavaScript
Images
Fonts
API requests

and requests those resources as necessary.

Finally, the browser renders the page.

DNS Transport

DNS traditionally runs over UDP port 53 for ordinary lookups (fast, low overhead), falling back to TCP port 53 for large responses or zone transfers. Traditional DNS is also unencrypted by default — a network observer can see which domains you're looking up.

Newer transports address this:

• DoT — DNS over TLS
• DoH — DNS over HTTPS
• DoQ — DNS over QUIC These encrypt the resolver conversation itself. Worth being precise about scope, though: encrypting DNS protects that channel — it doesn't make your broader internet traffic anonymous, and the destination IP you eventually connect to is still visible to your network.

What About CDNs?

DNS gets especially interesting once a CDN (Content Delivery Network) is involved.

Normally, DNS points a domain at one server — your origin server, sitting in one physical location. But if myapp.com is served through a CDN, the DNS response doesn't point at your server directly. It points at the CDN's network instead, and the CDN decides which of its servers actually responds to you.

Browser
   │
   │ "Where is myapp.com?"
   ▼
DNS
   │
   │ points to the CDN's network
   ▼
CDN picks the nearest edge server to you
   │
   ▼
That edge server replies (often from cache)

Why bother? Because "nearest to you" is the whole point. A CDN runs copies of your content — or at least a fast path to it — from dozens or hundreds of locations worldwide, called edge servers. Someone in Tokyo and someone in London requesting the exact same domain can each get routed to a different edge server, simply because DNS resolves differently depending on where the request is coming from. That's what makes a website feel fast no matter where its visitors are, instead of everyone making a long round trip to one server on the other side of the world.

Try It Yourself

dig google.com          # basic lookup
dig google.com MX       # specific record type
dig +trace google.com   # walk the hierarchy yourself
dig @1.1.1.1 example.com  # query a specific resolver directly

dig +trace is genuinely one of the best ways to see the Root → TLD → Authoritative hierarchy happen instead of just reading about it. Comparing dig @1.1.1.1 against dig @8.8.8.8 for the same domain is a good way to catch caching differences between resolvers in the wild.

Common Misconceptions

• "My browser always contacts the root DNS server." No — a recursive resolver does that work, and only when it can't already answer from cache.
• "Every lookup goes Root → TLD → Authoritative." No — caching (including negative caching) makes most real-world lookups much shorter.
• "The authoritative server always returns an IP." Not necessarily — it can return CNAME, MX, TXT, NS, and other record types.
• "DNS changes are immediate." Not necessarily — cached records (positive and negative) persist until their TTL expires.
• "DNS is just a simple database." It's a distributed, hierarchical, delegated, and heavily cached system — the caching is doing most of the practical work.

DNS in One Example

Suppose you enter:

https://api.myapp.com/users

A simplified journey might look like:

1. Browser needs api.myapp.com
              ↓
2. Local cache checked
              ↓
3. OS resolver checks local information
              ↓
4. Query sent to recursive resolver
              ↓
5. Resolver checks its cache
              ↓
6. If necessary:
       Root
        ↓
       .com
        ↓
       myapp.com authoritative DNS
              ↓
7. DNS record returned
              ↓
8. Resolver caches the result
              ↓
9. Your computer receives the address
              ↓
10. Browser establishes network connection
              ↓
11. TLS secures HTTPS
              ↓
12. Browser sends:
       GET /users
              ↓
13. API server processes request
              ↓
14. Server returns response
              ↓
15. Browser/application receives it

Notice something important:

DNS is only one part of the journey.

The complete path is more like:

Domain name
     ↓
DNS
     ↓
IP address
     ↓
Network connection
     ↓
TLS
     ↓
HTTP
     ↓
Application server

Summary

DNS is one of the fundamental pieces that makes the internet usable.

It transforms human-friendly names into information that computers can use to locate services — while caching, delegation, and a distributed hierarchy allow billions of devices to perform these lookups efficiently.

Once you understand DNS, concepts like CDNs, load balancers, reverse proxies, domain configuration, HTTPS, service discovery, and production networking become much easier to reason about.