How DNS Works: A Beginner's Guide
Every time you load a website, four different servers quietly cooperate to turn a name into an address. Here's what each one does, and why it usually finishes before you notice.
Quick Answer
DNS (Domain Name System) translates a domain name like dnsfly.net into an IP address like 104.21.0.1, because computers route traffic by number, not by name. Your device asks a recursive resolver, which asks a root server where the TLD lives, then the TLD server where the domain lives, then the domain's authoritative nameserver for the actual record. The answer gets cached at every step, so the next lookup skips most of that work. The whole thing usually takes 20 to 120 milliseconds the first time and under a millisecond after that.
Why DNS Exists
Computers connect to each other using IP addresses. People remember names. DNS is the layer that bridges the two, and it's the reason you type github.com instead of memorising a string of numbers.
A single central list would never work at internet scale. It would be a bottleneck, a single point of failure, and impossible to keep current. So DNS is distributed instead. No server knows every domain. Each one knows a small piece and knows who to ask next.
That delegation is the whole design. Understanding who delegates to whom is most of understanding DNS.
The Four Servers Involved
1. The recursive resolver
The one your device actually talks to. It's usually run by your ISP, or a public resolver like Cloudflare's 1.1.1.1 or Google's 8.8.8.8. It does all the legwork and hands you back one answer. It also caches, which makes it the single biggest factor in how fast your lookups feel.
2. The root servers
The top of the hierarchy. There are 13 root server addresses (not 13 machines, but 13 anycast clusters spread over hundreds of physical locations). A root server doesn't know about your domain. It only knows which servers handle each top-level domain like .com or .net.
3. The TLD nameservers
One set per top-level domain. The .com servers know which nameservers are responsible for every .com domain. They still don't know the IP address of the site, only who to ask.
4. The authoritative nameserver
The source of truth for one domain. This is where the actual records live, and it's what you're editing when you change DNS settings at your registrar or DNS host. Its answer is final, which is what "authoritative" means. See DNS vs nameservers for how these two terms differ.
A Lookup, Step by Step
Say you type example.com into a fresh browser on a machine that has never looked it up. Here's the full path.
- Step 1: Your device checks its own cache.
The browser checks first, then the operating system. If either already has the answer and it hasn't expired, the lookup ends here in well under a millisecond.
- Step 2: The query goes to your recursive resolver.
If nothing local has it, your device asks the resolver configured on your network. The resolver checks its own cache too, and it serves a lot of users, so popular domains are often already there.
- Step 3: The resolver asks a root server.
"Where do I find .com?" The root replies with the addresses of the .com TLD nameservers. It does not know anything about example.com itself.
- Step 4: The resolver asks a .com TLD server.
"Who is authoritative for example.com?" The TLD server replies with that domain's nameservers, which is the information stored in its NS records.
- Step 5: The resolver asks the authoritative nameserver.
"What is the A record for example.com?" This server actually has the answer and returns the IP address, along with a TTL saying how long the answer stays valid.
- Step 6: The answer travels back and gets cached.
The resolver caches it, hands it to your operating system, which caches it, which hands it to your browser, which caches it. Your browser opens a connection to that IP and the page starts loading.
Steps 3 through 5 are the expensive part, and they only happen on a cold lookup. Every later request for that domain jumps straight from step 1 or 2 to the answer.
Caching Is What Makes DNS Fast
Every record carries a TTL, a time to live measured in seconds. It tells anyone who receives that record how long they may reuse it before asking again. A TTL of 3600 means one hour.
Caching happens at four layers, and each one holds its own independent copy: your browser, your operating system, your recursive resolver, and sometimes your router. That redundancy is why DNS scales to billions of queries without melting the root servers.
The tradeoff: caching is also why DNS changes aren't instant. A long TTL makes lookups fast but changes slow. A short TTL makes changes quick but sends more traffic to your nameservers. Most people set a low TTL a day before a planned migration, then raise it again afterwards. TTL explained covers how to pick a value.
If you've changed a record and still see the old value, a cache is almost always the reason. You can clear your own with a DNS cache flush, but you can't clear anyone else's. Theirs expires on its own schedule.
The Record Types You'll Actually Use
A domain's DNS is just a set of records. There are dozens of types, but six cover almost everything you'll do day to day.
| Type | What it does | Typical value |
|---|---|---|
| A | Points a name at an IPv4 address | 93.184.216.34 |
| AAAA | Same, but IPv6 | 2606:2800:220:1:: |
| CNAME | Aliases one name to another name | www → example.com |
| MX | Says which server receives email | 10 mail.example.com |
| NS | Names the authoritative servers | ns1.example.com |
| TXT | Free-form text, used for verification and email auth | v=spf1 include:... |
TXT records are where SPF, DKIM, and DMARC live, which is why a single record type ends up doing most of the work in email security.
Watch a Lookup Happen
Reading about the hierarchy is one thing. Watching a resolver walk it is better. The +trace flag makes dig do the recursion itself and print every hop.
# The simple answer
dig example.com A +short
# The full path: root, then TLD, then authoritative
dig example.com A +trace
# Ask a specific resolver instead of your default
dig @1.1.1.1 example.com A
# Windows equivalent
nslookup example.com
Run the +trace version and you'll see the four steps from earlier appear as real output: a list of root servers, then the TLD servers, then the domain's own nameservers, then the record.
A plain dig example.com A also shows the remaining TTL as a number in the answer section. Run it twice a few seconds apart and watch that number count down. That's the cache expiring in real time.
What Happens When You Change a Record
Your edit lands on the authoritative nameserver immediately. That part is instant. What isn't instant is everyone else finding out.
Every resolver that already cached the old value keeps serving it until its TTL runs out. Different resolvers cached it at different moments, so they expire at different moments. That staggered expiry is what people call DNS propagation, and it's why a change can look live for you and stale for a colleague at the same time.
The common mistake: assuming a change failed because it hasn't appeared yet. Before you edit anything a second time, confirm the authoritative server has the new value. If it does, the record is correct and you're only waiting on caches. Editing again mid-propagation is how a simple change turns into a confusing one. See the troubleshooting guide for the full flow.
Checking from many locations at once is the fastest way to tell the difference between "still propagating" and "actually broken". If some regions return the new value and others return the old one, it's propagation. If nowhere has it, the record itself needs another look.
See DNS Resolution From 21 Locations
Now that you know what the resolvers are doing, watch them do it. DNSFly queries 21 DNS servers worldwide and shows you exactly which ones have your record and which are still serving a cached answer.