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:
gsmelevate.com?"
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.
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.
.com nameservers know where every .com domain's nameservers are.
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).
.com?"Root says: "Ask the
.com nameservers at Verisign."
.com nameservers
"Where can I find example.com?".com says: "Ask
ns1.example.com and ns2.example.com."
blog.example.com?"example.com says: "It's
93.184.216.34."
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.
; <<>> 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.
example.com → 93.184.215.14example.com → 2606:2800:21f:cb07You can ask for any of these directly with dig.
$ 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:
- 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.
- 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.
# 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.
dig @authoritative.server shows you the live answer directly.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.
# 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.