What Is DNS? A Beginner-Friendly Guide to How Domain Names Become IP Addresses

When you type google.com or toolcluster.app into your browser, a web page comes back from a server somewhere in the world in an instant. If you stop and think about it, several mysterious things have just happened in a row.

• You type toolcluster.app and an article shows up from a server somewhere in the world. But where exactly did the address (the IP address) come from?
• Connect a phone to Wi-Fi and Google and YouTube just work. Who is converting the domain name into an IP address behind the scenes?

Most of us use this without ever thinking about it. But trace it back, and you’ll find a distributed phone book stretched across the entire internet, quietly working behind the curtain.

Devices on the internet can’t talk to each other without an IP address (the numeric address on the network) ─ see our previous article What Is an IP Address?. But day to day, we don’t punch in numbers like 192.168.1.10; we type human-friendly names like toolcluster.app. The thing that bridges the two is DNS (the Domain Name System).

In this article we’ll unpack:

• What DNS actually is and why it’s needed (§1)
• Why domain names read meaningfully from right to left (§2)
• What happens behind a single name lookup ─ the 7-phase journey (§3)
• What DNS records really are (§4)
• The DNS cache and TTL that quietly hold up 90% of the internet (§5)
• The era of encrypted DNS via DoH/DoT (§6)
• How CDNs and Apple Private Relay relate to DNS (§7)
• A few commands you can run to observe DNS on your own machine (§8)

We’ll go step by step with diagrams, assuming zero prior background.

1. What is DNS ─ the “phone book” of the internet

1-1. The job of linking names to addresses

A phone book is a way to look up a phone number from a person’s name. On the internet, the equivalent pieces are:

• Domain name ─ the human-friendly string, like the person’s name (toolcluster.app)
• IP address ─ the number machines use to actually communicate, like the phone number (203.0.113.5)

The “phone book” that ties these two together is DNS (the Domain Name System ─ the system used by the entire internet to convert “names → addresses”).

1-2. Why DNS is necessary

If pure connectivity were the only goal, you could just type IP addresses. But DNS exists for three reasons:

• Hard to remember: toolcluster.app is dramatically easier to recall than 203.0.113.5
• Subject to change: IP addresses change as you migrate servers or switch cloud providers. If users only need to remember the name, the underlying address can change without them noticing
• Distribute across many servers: tie one name to multiple IPs and route users to different servers around the world (this is what CDNs do, more on that later)

1-3. DNS is not a single giant database

This is the most common misconception. People imagine “a DNS headquarters somewhere in the world that manages every domain.” In reality, DNS is a distributed, hierarchical system spread across the entire internet.

your browser
        ↕
    DNS resolver (a "proxy" that handles name resolution on your behalf)
        ↕
   DNS server fleet, scattered around the world
        ├── Root servers (".")
        ├── TLD servers (".app", ".com", etc.)
        └── Authoritative name servers (operated by each domain owner)

For example, the only servers that truly know the address for toolcluster.app are the authoritative name servers for toolcluster.app, sitting somewhere in a corner of the world. Every other server can only say “not me, ask over there.” DNS is fundamentally about dividing the work and passing the question along until you find the answer.

2. The hierarchy of domain names ─ read right to left

2-1. Like a postal address, the right side is “wider”

A domain name like www.toolcluster.app works just like a postal address: the further right you go, the wider the scope.

www . toolcluster . app .
└─┬─┘  └────┬─────┘ └┬┘ └← the trailing "." is usually omitted but represents the root
  sub        second   TLD
  domain     level

Just like an English postal address goes “house number → street → city → state → country” with the largest unit on the right. The often-omitted trailing dot (.) represents the largest unit of all: the root.

2-2. Four tiers, each with a “person in charge”

The DNS hierarchy has four tiers:

• Root (.): the very top of the internet. Operated as 13 server clusters worldwide
• TLD (Top Level Domain): .com, .app, .jp, and so on. Operated by Verisign, Google, and others
• Second-level domain: the toolcluster part of toolcluster.app. The buyer of the domain takes responsibility
• Subdomain: the www part of www.toolcluster.app. The owner can split it freely

Each tier has its own person in charge (the authoritative name server ─ the server that “really knows” the IP for the domains in its scope). The lookup journey works by walking down from the top tier and following the chain of responsibility until you reach the answer.

.                            ← root (".")
├── com                      ← TLD
├── app                      ← TLD ★ ask the ".app" people from here
│    └── toolcluster         ← second-level ★ this is where the authoritative NS lives
│         └── www            ← subdomain
├── jp
└── ...

3. ★ The name resolution journey ─ 7 phases

This is the heart of the article. From the moment you type toolcluster.app until your browser has the IP address in hand, what is actually happening? We’ll trace it through 7 phases.

3-1. Timeline of the 7 phases

Each phase takes a few milliseconds to a few hundred milliseconds. If a cache hit happens at any point during 1 to 6, every phase below it is skipped (more in §5).

1. 1Check the browser cacheHas this domain been resolved very recently? The browser checks its internal table first.
2. 2Ask the OS stub resolverIf the browser doesn’t have it, ask the small DNS client built into the OS (the stub resolver). The OS has its own cache too.
3. 3Send to the DNS resolverIf the OS doesn’t have it either, the question is sent to an external DNS resolver (your ISP’s, 8.8.8.8, 1.1.1.1, etc.).
4. 4Ask a root serverThe resolver asks the root: “who handles .app?”
5. 5Ask the TLD serverThe resolver asks the .app TLD server (pointed to by root): “who handles toolcluster.app?”
6. 6Ask the authoritative name serverFinally, the resolver asks toolcluster.app’s authoritative NS: “what is the IP for www.toolcluster.app?”
7. 7The answer flows back to the browserThe answer travels back resolver → OS → browser, and is cached at every layer along the way.

Memory hook: “Browser → OS → Resolver → Root → TLD → Authoritative → Back.” From the moment you press Enter to the moment the answer arrives, every lookup walks through these 7 stops (most are short-circuited by cache, but the full path is this).

3-2. Iterative vs recursive ─ “who is being passed around?”

If you watch those 7 phases carefully, you’ll notice there are actually two different styles of question.

• Recursive query: you (the browser/OS) ask the DNS resolver “just give me the final answer.” The resolver does steps 4–6 on your behalf
• Iterative query: the DNS resolver asks each upstream server “just tell me who I should ask next.” The resolver gets passed from server to server, collecting the answer step by step

So the only thing being passed around is the resolver. You just say “resolver, take care of it.” This design is what makes the internet feel as fast as it does.

4. DNS record types

DNS doesn’t only return “name → IP.” A domain has all kinds of related information attached as records, each with its own type. Here are the 8 most important ones.

A and AAAA are the IPv4/IPv6 pair, and modern sites typically configure both. CNAME means “alias,” so by setting www.toolcluster.app as an alias of toolcluster.app, you only need to update one IP and both names follow.

MX, TXT, and NS show up when services other than the Web attach to a domain. If you want email, you set MX; for domain authentication and anti-spoofing, you put SPF/DKIM/DMARC into TXT records ─ that’s the standard playbook.

5. DNS cache and TTL ─ the unsung hero of the internet

If we ran the full 7-phase journey from §3 for every single connection, the root servers would buckle under hundreds of millions of queries per second. In reality the cache absorbs almost everything, and most lookups end at phase 1, 2, or 3.

5-1. The cache has many layers

browser internal cache
        ↓ if miss
OS stub resolver cache
        ↓ if miss
DNS resolver cache (ISP / 8.8.8.8 / 1.1.1.1)
        ↓ if miss
the actual journey: root → TLD → authoritative

The more layers there are, the less load goes upstream (root and TLD).

5-2. TTL ─ when to throw the cache away

Every record has a TTL (Time To Live ─ the maximum number of seconds the record may be cached) attached to it. If TTL = 300, then the cache can be reused for 5 minutes; after that it must be discarded and refetched.

• Setting TTL longer → less upstream load, but IP changes take longer to propagate
• Setting TTL shorter → changes propagate quickly, but more queries hit upstream

The classic playbook before a server migration is to “lower the TTL to 60 seconds first, then migrate” ─ that’s exactly this property in action.

5-3. “DNS propagation” isn’t actually propagation

You’ll often hear the phrase “waiting for DNS to propagate” during a site migration. It’s frequently misunderstood: it really just means “waiting for caches around the world to expire”. The new record is not literally being broadcast across the planet.

• ✗ Common misconception: the new IP is being propagated to every DNS server in the world
• ✓ Reality: each resolver simply refetches from the authoritative NS the moment its old cache TTL expires

Which is why lowering the TTL ahead of time speeds “propagation” up. Once you understand the mechanism it’s obvious; without it, this stage feels like sitting back and hoping for the best.

6. DoH / DoT ─ the era of encrypted DNS

Up to now we’ve been quietly assuming that “DNS queries fly across the network in plain text.” For a long time, that was true. But in the 2020s the tide is shifting.

6-1. The problem with plain-text DNS

In plain text, your DNS queries are visible to anyone on the same network.

• Public Wi-Fi operators can clearly see “what you’re trying to visit” (the domain names)
• ISPs can build a domain-level browsing history
• A man-in-the-middle could forge records and redirect you to a fake site (DNS spoofing)

6-2. Enter DoH and DoT

The answer is DoH (DNS over HTTPS) and DoT (DNS over TLS). Both encrypt the DNS query.

6-3. Today’s deployment

Major browsers (Firefox / Chrome / Safari) automatically use DoH under the right conditions. On the corporate side, this introduces a new challenge: “how do we govern DoH?” ─ because parental filters and intrusion detection systems were watching DNS.

This topic deserves its own dedicated article, so for now, just hold onto the high-level shape: “DNS is being encrypted, and that has consequences.”

7. CDN and DNS ─ the clever lie of “the nearest server”

To wrap up, two real-world applications of DNS that power modern Web performance.

7-1. CDNs return “the nearest one” via GeoDNS

If you resolve google.com from different countries, you’ll get different IPs back depending on where you are. The authoritative name server is looking at the source location and network path of the query, and returning the IP of the closest server. This is called GeoDNS (operating DNS so it returns geographically optimal answers). CDNs (content delivery networks) like Cloudflare and Akamai run this at massive scale.

a user in Tokyo → IP of the Tokyo edge server
a user in New York → IP of the New York edge server

Same domain, different answers ─ this is how DNS now goes well beyond a “simple phone book.”

7-2. Apple Private Relay also hinges on DNS

On iOS / macOS, Apple Private Relay is a service that splits your DNS queries and your Web traffic across two relays so that no single party can correlate them. The starting point of “even Apple can’t see what you’re browsing” is exactly DNS encryption and separation.

So DNS now goes beyond plain name resolution and serves as a hinge for both privacy and delivery optimization.

8. Observe DNS on your own machine

Once you’ve followed the theory, it’s worth getting your hands on it. Deeper usage deserves its own article, so here we’ll show only the two minimal commands you need.

8-1. dig (Linux / macOS)

dig toolcluster.app

In the output, the part you want is everything below ;; ANSWER SECTION:.

;; ANSWER SECTION:
toolcluster.app.    300    IN    A    203.0.113.5

300 is the TTL, A is the record type, and 203.0.113.5 is the IP. Once you can read those three numbers, the knowledge from §4 and §5 becomes muscle memory.

8-2. nslookup (Windows / cross-platform)

nslookup toolcluster.app

The Server: line shows “the DNS resolver you’re currently using”; the Address: line shows “the IP for the domain.”

8-3. Clearing the cache

• Windows: ipconfig /flushdns
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux (systemd): sudo systemd-resolve --flush-caches

There’s a lot more to dig, but that’s a topic for another article. For this one, “type one line, learn how to read the answer” is enough.

Summary ─ the 4-line essence

This was a long article, but the essence fits in 4 bullets.

• DNS = the name-to-address converter. It runs on a network of servers spread across the world
• Domain names are hierarchical, read right to left, and each tier has a person in charge (the authoritative name server)
• Cache and TTL hold up about 90% of the internet. “DNS propagation” isn’t propagation; it’s waiting for TTLs to expire
• Knowing DoH/DoT and CDN is what lets you make sense of how the modern internet behaves

With this skeleton in your head, planning a site migration, isolating odd latency issues, and reading DNS-related news all become the same kind of task.

For the network address itself, see What Is an IP Address?; for the bridge between OS and software, see Why Do We Need to Install Software?; and for resetting accumulated OS state, see Why Does a Restart Fix My Computer?. Read together, the “invisible plumbing” of the PC and the internet starts to connect into a single, three-dimensional picture.

FAQ

Q1. What can I do when DNS feels slow?

A. The first two suspects are cache and resolver choice. If clearing the local cache (ipconfig /flushdns on Windows, equivalents elsewhere) doesn’t help, switching the DNS resolver to a public one such as 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), or 9.9.9.9 (Quad9) often makes things faster. You can change this in your home router as well. Also note: sites with a long TTL can feel “uniformly slow for everyone” because of server-side reasons, so it helps to check whether other people are experiencing the same slowness.

Q2. What is the hosts file? How does it relate to DNS?

A. The hosts file is a local address book that the OS consults before DNS. On Mac/Linux it lives at /etc/hosts; on Windows at C:\Windows\System32\drivers\etc\hosts. Add a line like 127.0.0.1 myapp.local and traffic to myapp.local goes to your own machine without DNS being involved at all. It’s commonly used during development or to block specific sites. Because it sits in front of DNS, a stray edit can leave you wondering “why can’t I reach this site?”

Q3. What happens between buying a domain and it appearing on the Web?

A. There are roughly 3 steps. (1) Buy the domain at a registrar (Namecheap, Cloudflare Registrar, etc.); the TLD database is updated with your registration. (2) Specify the authoritative name servers (NS) in the registrar’s control panel ─ either run your own or use a managed DNS like Cloudflare DNS or Route 53. (3) On those authoritative NS, configure A or CNAME records pointing to your server’s IP. From that point, resolvers around the world will pick up the new record as their TTLs expire.

Q4. 8.8.8.8 vs 1.1.1.1 ─ which one should I use?

A. Both are stable, free public DNS resolvers. Speed is usually a tie outside of regional differences, so the choice comes down to policy and extra features. 8.8.8.8 (Google) brings massive infrastructure and a long track record; 1.1.1.1 (Cloudflare) leans on “logs deleted within 24 hours” privacy commitments. If you want filtering (block adult content, etc.), 1.1.1.3 (Cloudflare for Families) and 9.9.9.9 (Quad9, blocks malware domains) are options. For home or personal use, 1.1.1.1 is a safe default; for business use where you want SLAs and support, leaning on your ISP’s DNS or a paid service is more pragmatic.

Q5. Does enabling DoH break corporate security?

A. Half true; half already addressed. Older corporate security relied on “watching DNS to block suspicious domains,” and DoH does hide DNS inside HTTPS, which weakens that approach. But modern enterprise environments compensate via endpoint agents on the PC, or by forcing DoH through an internal resolver. There’s no major risk in personal use, but on a company-issued PC, don’t enable DoH on your own ─ it’s likely to conflict with corporate policy.