Skip to content

Free Weekly IT Class

Learn more
← Back to Blog

How DNS Works (Without the Jargon)

May 2, 2026  ·  GSM.elevate() Team  ·  11 min read


A Phone Book the Size of the Internet

Computers don’t talk to each other using names like wikipedia.org. They talk using numbers called IP addresses, things like 208.80.154.224. Names are for humans. Numbers are for the network.

The Domain Name System (DNS) is the bridge between the two. It’s the global phone book that translates names into numbers. Every time you load a website, send an email, or use an app, DNS does its work in the background, usually without you noticing.

The good news: it’s not magic. It’s a clearly defined process with about four steps. Once you see the flow, the whole thing makes sense.

The 5-Second Version

When you type gsmelevate.com into your browser:

1
Your computer asks a resolver "Hey, what's the IP address for gsmelevate.com?"
2
The resolver hunts it down It walks up the DNS hierarchy until it finds the answer.
3
The IP address comes back Now your computer knows where to send the request.
4
Your browser connects It opens a connection to that IP address and asks for the page.

That whole sequence usually takes less than 100 milliseconds. Sometimes less than 20.

The interesting part is step 2. Let’s zoom in.

The Four Layers of DNS

The DNS system is organized as a hierarchy. Picture a tree, with each layer responsible for a smaller slice of the internet.

A
The recursive resolver Usually run by your ISP, your router, or a public service like Cloudflare's 1.1.1.1 or Google's 8.8.8.8. This is the resolver your computer talks to. It does the actual work of finding the answer.
B
The root nameservers Thirteen sets of servers (named A through M) that know one thing: where to find the nameservers for every top-level domain. They're the entry point.
C
The TLD nameservers Operated by the company that runs each top-level domain. The .com nameservers know where every .com domain's nameservers are.
D
The authoritative nameservers The actual servers that hold the records for a specific domain. These are the source of truth. Whatever they say is the official answer.

When you ask a question, the resolver walks down through these layers until it has an answer.

A Real Example, Step by Step

Let’s resolve blog.example.com. The resolver starts with nothing in its cache (we’ll get to caching later).

1
Resolver to root nameservers "Where can I find .com?"
Root says: "Ask the .com nameservers at Verisign."
2
Resolver to .com nameservers "Where can I find example.com?"
.com says: "Ask ns1.example.com and ns2.example.com."
3
Resolver to example.com's nameservers "What's the IP for blog.example.com?"
example.com says: "It's 93.184.216.34."
4
Resolver to your computer "Here's the answer: 93.184.216.34."

That’s the full chain. Three queries, one answer. In practice, most of those steps are cached, so you usually only hit one or two layers before getting the answer.

You can watch this happen in real time on your own machine. Try this in a terminal.

~ — bash
$ dig +trace example.com

; <<>> DiG 9.18 <<>> +trace example.com ;; global options: +cmd . 518400 IN NS a.root-servers.net. . 518400 IN NS b.root-servers.net. ;; Received 239 bytes from 192.168.1.1#53(192.168.1.1) in 4 ms

com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. ;; Received 1174 bytes from 198.41.0.4#53(a.root-servers.net) in 8 ms

example.com. 172800 IN NS a.iana-servers.net. example.com. 172800 IN NS b.iana-servers.net. ;; Received 533 bytes from 192.5.6.30#53(a.gtld-servers.net) in 12 ms

example.com. 300 IN A 93.184.215.14 ;; Received 56 bytes from 199.43.135.53#53(a.iana-servers.net) in 28 ms

That’s the entire DNS hierarchy unrolled in front of you. Root, then .com, then example.com, then the answer. Each line shows which server gave the response and how long it took.

DNS Records: The Different Kinds of Answers

A DNS lookup doesn’t always return an IP address. It returns whatever record type you ask for. Here are the ones you’ll meet most often.

A
IPv4 Address
Maps a name to an IPv4 address. The most common record type.
example.com → 93.184.215.14
AAAA
IPv6 Address
Same idea as A, but for IPv6 addresses. Pronounced "quad-A."
example.com → 2606:2800:21f:cb07
CNAME
Canonical Name
Points one name at another name. The resolver follows the chain until it finds an A or AAAA record.
MX
Mail Exchange
Says where to deliver email for this domain. Used by mail servers, not browsers.
TXT
Text
Free-form text. Used for proof-of-ownership, email security (SPF, DKIM, DMARC), and other metadata.
NS
Nameserver
Says which nameservers are authoritative for this domain. Set at the registry level.

You can ask for any of these directly with dig.

querying record types
$ dig gsmelevate.com A +short 104.21.34.91 172.67.198.58

$ dig gmail.com MX +short 5 gmail-smtp-in.l.google.com. 10 alt1.gmail-smtp-in.l.google.com. 20 alt2.gmail-smtp-in.l.google.com.

$ dig example.com TXT +short “v=spf1 -all” “protocol=TLSv1.2,TLSv1.3…”

$ dig gsmelevate.com NS +short aida.ns.cloudflare.com. walt.ns.cloudflare.com.

The +short flag strips out everything except the answer. Without it, you see all the headers and timing info.

TTL and “DNS Propagation”

Every DNS record has a number attached called a TTL (time to live). It tells resolvers how long they can cache the answer before they need to re-check.

A TTL of 300 means “you can cache this for 300 seconds (5 minutes).” A TTL of 86400 means “cache for 24 hours.”

Caching is what makes DNS fast. Without it, every page load would involve four round-trips to authoritative servers around the world. With it, most lookups hit a local cache and return in milliseconds.

But caching is also where the term “DNS propagation” comes from, and it’s the source of about half the DNS confusion in the world.

DNS doesn’t actually propagate. When you change a record, the change happens instantly at the authoritative nameserver. What takes time is waiting for the old, cached answer to expire from every resolver around the world that’s still holding onto it.

If your old TTL was 24 hours, some resolvers will hang onto the old answer for up to 24 hours. There’s no way to force them to drop it. This is why people say “DNS changes can take up to 48 hours.”

Two practical takeaways:

  1. Lower your TTL before you make a change. A day before you plan to update a record, drop the TTL to something low like 300. Once the old (long) TTL expires, all the caches will start respecting the new (short) TTL. When you make the actual change, propagation is fast.
  2. You can always verify the truth at the source. Query the authoritative nameserver directly with dig @ns1.example.com example.com. That bypasses every cache and gives you the live answer.
checking the source of truth
# What does my local resolver say? $ dig gsmelevate.com +short 104.21.34.91

# What does the authoritative server say? $ dig @aida.ns.cloudflare.com gsmelevate.com +short 104.21.34.91

# If those disagree, your local cache is stale. # If they agree, you’re seeing the current truth.

Your Registrar vs Your DNS Provider

Here’s the part that surprises a lot of people. Your registrar and your DNS provider don’t have to be the same company.

Your registrar is who you bought the domain from. They control the NS records at the registry, which is the pointer that says “go ask these nameservers for everything else.”

Your DNS provider is whoever actually answers the questions. By default, that’s also your registrar (most include free DNS hosting). But you can point your domain at any DNS provider you want.

Common reasons to split them:

  • Your registrar’s DNS controls are limited or slow.
  • You want a faster DNS provider (Cloudflare’s network is famously fast).
  • You want features your registrar doesn’t offer, like API control or advanced record types.
  • Your DNS provider goes down and you want to switch without changing registrars.

To split them, you change the NS records at your registrar to point at the new DNS provider. From that point forward, the new provider answers all the questions.

Good Things to Know About DNS

A few details that often get overlooked. Knowing them upfront saves a lot of head-scratching later.

// speed
DNS is fast (with caching)
Cold lookups can take a moment. Cached lookups usually return in under 5ms. Once a name is resolved, the answer stays close to you.
// debugging
Always check the source of truth
When something looks off, a stale cache is usually the cause. dig @authoritative.server shows you the live answer directly.
// abstraction
You rarely need raw IPs
Hosts and CDNs typically give you a hostname (a CNAME target). The underlying IP can change without affecting your site at all.
// security
Security is a separate layer
DNSSEC adds verification of answers. DNS-over-HTTPS adds encryption of queries. Both are opt-in features worth enabling.

Tools You Can Play With Right Now

You don’t need to install anything. Most of these are built into macOS, Linux, and Windows already.

~ — try these
# Quick lookup (Mac/Linux) $ dig gsmelevate.com

# Even quicker $ dig gsmelevate.com +short

# Look up a specific record type $ dig gsmelevate.com MX

# Trace the full hierarchy $ dig +trace gsmelevate.com

# Reverse lookup (IP back to name) $ dig -x 1.1.1.1 +short one.one.one.one.

# On Windows, use nslookup instead > nslookup gsmelevate.com

You can also use a web tool like dnschecker.org or whatsmydns.net to see how a domain resolves from different parts of the world. They’re useful when you’ve made a change and want to see how widely it’s been picked up.

Putting It Together

Once you understand DNS, the common scenarios make sense and have clear answers:

  • Setting up a new site: point an A record at your host’s IP, or a CNAME at the hostname they give you, and you’re live as soon as caches refresh.
  • Different results on different devices: that’s caching at work. Each device has its own cache that expires on its own schedule.
  • Recent changes catching up: the old TTL is the timer. Once that expires everywhere, the new answer takes over.
  • Email setup: the TXT records (SPF, DKIM, DMARC) are how mail providers verify a sender. Most email providers give you the exact records to add.

DNS is a database of records, organized in a hierarchy, with caching for speed. Once that’s the mental model, everything else falls into place.

Where to Go From Here

If you haven’t already, our companion post on domain registrars covers the part that happens before DNS: how you actually get a domain in the first place, and what to look for in a registrar.

If you’d rather see this in action, come to a Thursday class at the E.G. Fisher Library. We register real domains, configure real DNS, and get real sites live, all in 60 minutes.

Or join the Discord. DNS comes up a lot, and there’s usually someone happy to help you trace through a lookup with you.


// COMMUNITY

Ready to Start Your Ascent?

Join hundreds of learners, mentors, and professionals in our Discord community. Free forever.

Join the Discord

Free to join · No account required