How DNS Works: The Internet’s Address Book Explained
Business & Professional Services

How DNS Works: The Internet’s Address Book Explained

Avatar photo
Sarah Whitmore October 6, 2026 18 min read

Early in my career, a senior engineer gave me a lesson about how DNS works that I still repeat to every junior tech I train: “It’s always DNS. And when it isn’t DNS, check DNS again.” I laughed the first time I heard it. Then I spent a Friday night chasing what looked like a dead web server, a broken load balancer, and a firewall rule gone wrong, only to find a single stale record sitting in a resolver cache. The server was fine. The network was fine. The address book was wrong.

That night taught me more about how DNS works than any certification course did. If you run a business that depends on a website, email, a customer portal, or cloud software, DNS is quietly holding all of it together. Most owners never think about it until something breaks. My goal here is to walk you through the system the way I explain it to clients and new hires: plainly, with real examples, and with the parts that actually matter when you’re the one on the phone at 2 a.m.

The Basics of How DNS Works

DNS stands for Domain Name System. At its core, it translates names humans remember into numbers computers route on. You type foretec.com. Your computer has no idea where that is. What it needs is an IP address, something like 203.0.113.25 for IPv4 or a much longer string for IPv6. DNS is the service that answers the question “where does this name live?”

The phone book comparison is old, but it still explains how DNS works better than most diagrams. You know your accountant’s name, not their number, so you look the name up and get the number. DNS does the same thing billions of times a day, across every country, in a few milliseconds per lookup when things are healthy.

What makes DNS impressive is not the lookup itself. It’s that no single company owns the whole book. The system was designed in the 1980s to be distributed, hierarchical, and delegated. The original specifications, RFC 1034 and RFC 1035, published in 1987, still describe the foundation we use today. Very few technologies survive four decades with their core design intact. DNS did, because the design was right.

The Four Players Behind How DNS Works

You can’t really understand how DNS works without meeting the cast. When I whiteboard this for a client, I draw four boxes.

The recursive resolver. This is the workhorse. It’s usually run by your internet provider, your company’s IT team, or a public service such as Cloudflare’s 1.1.1.1 or Google’s 8.8.8.8. Your laptop asks the resolver a question and the resolver does all the legwork to find the answer.

Root name servers. These sit at the very top of the hierarchy. They don’t know where your website is. What they know is who is in charge of each top level domain, like .com, .org, .ph, or .uk.

TLD name servers. TLD means top level domain. The .com servers, for example, are operated by Verisign. They don’t know your website’s IP address either, but they know which name servers are authoritative for your specific domain.

Authoritative name servers. This is where the real answer lives. When you set up DNS at your registrar, your hosting company, or a provider like Cloudflare or AWS Route 53, you’re editing records on an authoritative server. It holds the final truth for your domain.

Cloudflare’s learning center puts it well: every DNS server falls into one of four categories, recursive resolvers, root nameservers, TLD nameservers, and authoritative nameservers. Once you understand those four roles, the rest of the system clicks into place.

How DNS Works, Step by Step

Here is how DNS works during a real lookup. Say one of your customers opens a browser and types www.example.com.

1. The Local Check

Before anything leaves the machine, the operating system checks its own cache and the local hosts file. If the answer is already there from a recent visit, the lookup ends right here. This is why the second visit to a site often feels faster than the first.

2. The Stub Resolver Passes the Question Along

The computer itself runs a very simple piece of software called a stub resolver. It doesn’t hunt for answers. It just sends the question to whichever recursive resolver the network told it to use, usually handed out by your router through DHCP.

3. The Resolver Checks Its Cache

A busy resolver at an ISP answers millions of queries. Chances are good someone else already asked about a popular domain recently, so the answer may already be sitting in memory.

4. A Root Server Gives the First Referral

If the cache is empty, the resolver starts at the top. It doesn’t ask the root for the full answer. In effect it asks, “Who handles .com?” The root replies with a referral, a list of the .com TLD servers and their addresses.

5. The TLD Server Points the Way

Next the resolver asks a .com server, “Who handles example.com?” Again, it gets a referral, this time pointing to the authoritative name servers that the domain owner registered.

6. The Authoritative Server Answers

Finally, the resolver asks the authoritative server for www.example.com, and that server returns the actual record, the IP address.

7. The Answer Travels Back

The resolver caches the answer and hands it to your computer. Your browser then opens a connection to that IP address, and the page starts loading.

Seeing How DNS Works With Your Own Eyes

A recent technical write up on DNS resolution sums up the chain nicely: the root refers to the TLD, the TLD refers to the zone’s authoritative servers, and only the authoritative server returns the address. That’s how DNS works in a nutshell. Everything else is detail layered on top of those referrals.

When I’m troubleshooting, I watch this happen live with a command called dig, using the trace option. It walks the exact path from root to TLD to authoritative and prints every hop. If you manage infrastructure, learn that command. It has saved me more hours than any monitoring dashboard.

The 13 Root Servers and How DNS Works at the Top

Every few months a client asks me some version of, “Isn’t the whole internet running on 13 computers?” It’s one of the most persistent myths about how DNS works.

Here’s what’s really going on. There are 13 root server identities, labeled with the letters A through M. Each one has a fixed IPv4 and IPv6 address that resolvers know in advance through a small file called root hints. According to IANA, the root servers are actually a network of hundreds of servers in many countries around the world, configured as 13 named authorities. Today the count runs into the thousands. The Root Server Technical Operations Association reported that as of October 4, 2026, the root server system had 2045 operational instances run by 12 independent operators.

Anycast and How DNS Works at Global Scale

How do thousands of machines share 13 addresses? A routing technique called anycast. Many physical servers announce the same IP address from different locations, and the internet’s routing system delivers your query to whichever one is closest in network terms. A resolver here in Asia will usually reach an instance in the region rather than one in Virginia.

Why 13 and not 14 or 50? Historical packet size limits. The original DNS ran over UDP with a 512 byte message ceiling, and 13 was the practical maximum number of server names and addresses that fit in a single response. ICANN’s RSSAC FAQ explains that there are more than 1500 servers globally but only 13 root server identifiers, each using one IPv4 and one IPv6 address with anycast routing.

The operators are a mixed group on purpose: Verisign, the University of Maryland, NASA, ICANN, RIPE NCC, Netnod, the WIDE Project in Japan, the US Army Research Lab, and others. That diversity is a resilience feature. No single company or government can take the root down.

DNS Records: How DNS Works for Your Website and Email

When I hand a business owner access to their DNS dashboard, I usually tell them to ignore most of it and learn these record types well. They are where knowing how DNS works turns into something you can actually change.

Records That Point to Your Website

A record. Maps a name to an IPv4 address. This is the most common record you’ll see, and it’s usually what points your website to your web host.

AAAA record. Same idea, but for IPv6. More networks run IPv6 every year, so if your host supports it, publish one.

CNAME record. An alias. It says “this name is really that other name.” For example, shop.yourcompany.com might be a CNAME pointing to your e commerce platform. One rule I see broken constantly: you cannot put a CNAME on the bare root of your domain alongside other records. Many providers offer a workaround called ALIAS or CNAME flattening.

Records for Email and Verification

MX record. Tells the world which servers accept email for your domain. Get this wrong and your inbox goes silent while your website keeps working, which makes for a very confusing support call.

TXT record. A free text field that has become the backbone of email security and domain verification. SPF, DKIM, and DMARC all live here. So do the verification strings that Google, Microsoft, and dozens of SaaS tools ask you to add.

PTR record. The reverse of an A record. It maps an IP address back to a name. Mail servers check these, and a missing PTR is a common reason legitimate email lands in spam.

Records That Run the Zone

NS record. Lists the authoritative name servers for a zone. These records are what the TLD servers hand out during a referral.

SOA record. Start of Authority. It holds administrative details about the zone, including serial numbers and timing values that secondary servers use to stay in sync.

Caching and TTL: How DNS Works Behind the Scenes

If there is one concept I wish every business owner understood, it’s TTL, which stands for time to live. It shapes how DNS works more than almost anything else in day to day operations.

Every DNS record carries a TTL value in seconds. It tells resolvers how long they’re allowed to keep the answer in cache before asking again. A TTL of 3600 means one hour. A value of 86400 means a full day.

Caching is what makes DNS fast and keeps the root and TLD servers from collapsing under load. But it also explains the most common complaint that reaches the help desk: “I changed my DNS an hour ago and half my team still sees the old site.” They’re seeing a cached answer. Some resolvers picked up the new record already. Others are still holding the old one until its TTL runs out.

People call this “propagation,” but nothing is really being pushed out. Resolvers around the world are simply waiting for their cached copies to expire.

Planning a Change Around How DNS Works

Here’s the practical habit I drill into every team I work with. If you’re planning a migration, a host change, or an email cutover, lower the TTL on the affected records to something like 300 seconds a full day or two before the change. Then make the switch. The old values flush out within minutes instead of hours. After everything is stable, raise the TTL back up so you’re not generating needless traffic.

There’s also negative caching. If a resolver asks for a name that doesn’t exist, it caches that “no such domain” answer too, based on values in the SOA record. I’ve watched people create a new subdomain, test it too early, get a failure, and then wonder why it keeps failing for another fifteen minutes. The resolver remembered the earlier “no.”

Where DNS Goes Wrong in the Real World

After years of handling incidents, I can tell you DNS problems tend to fall into a handful of patterns. Once you know how DNS works, they become easy to spot.

Expired domains. This one is painful because it’s so avoidable. When a domain registration lapses, the registry pulls the delegation, and everything tied to that name stops resolving. Website, email, VPN, all of it. Turn on auto renew and keep the billing contact current.

Wrong name servers at the registrar. A company moves DNS hosting to a new provider, builds all the records perfectly, then forgets to update the NS delegation at the registrar. The new zone sits there, beautiful and ignored, while the world keeps asking the old servers.

A single point of failure. Running all your authoritative DNS on one provider is common and usually fine, until that provider has a bad day. Large outages over the years have shown that even major DNS providers can go down. For businesses where minutes of downtime cost real money, a secondary DNS provider is worth considering.

Typos and trailing dots. In raw zone files, a name without a trailing dot is treated as relative to the zone. Forget that dot and mail.example.com quietly becomes mail.example.com.example.com. Modern dashboards mostly hide this, but it still bites people who edit zone files directly.

Email authentication gaps. Missing or broken SPF, DKIM, and DMARC records don’t break email outright. They just make it slowly less reliable as receiving servers trust you less. For a professional services firm that lives on client email, that’s a serious problem hiding in plain sight.

DNS Security: How DNS Works When Someone Attacks It

Classic DNS was built for a more trusting internet. Queries and answers traveled in plain text, and resolvers mostly believed whatever came back. Any honest look at how DNS works has to cover the attacks that design opened the door to.

Common Attacks on DNS

Cache poisoning. An attacker tricks a resolver into caching a fake answer, so users asking for your bank or your login page get sent somewhere else. The 2008 Kaminsky vulnerability showed how practical this could be, and it pushed the industry to randomize source ports and query IDs.

DNS hijacking. Instead of attacking the resolver, the attacker gets into your registrar or DNS provider account and changes the records themselves. This is why I always recommend multi factor authentication and a registry lock on any domain that matters.

DDoS attacks against DNS. If attackers flood your authoritative servers, your site becomes unreachable even if the web servers are perfectly healthy. Anycast networks and large DNS providers absorb much of this, which is another argument against running your own single server in a closet.

Tools That Keep How DNS Works Secure

DNSSEC. DNS Security Extensions add digital signatures to DNS records. A validating resolver can check that an answer really came from the domain owner and wasn’t tampered with along the way. It doesn’t encrypt anything, but it does prove authenticity. ICANN has pushed DNSSEC adoption for years, and the root zone itself has been signed since 2010. Turning it on for your domain is usually a few clicks with a modern provider, plus adding a DS record at your registrar.

Encrypted DNS. DNS over HTTPS (DoH) and DNS over TLS (DoT) wrap queries in encryption so people on the same network, like a shared café Wi Fi, can’t easily see or alter which sites you’re looking up. Most major browsers and operating systems support one or both now. For companies, it’s worth deciding on a policy, since encrypted DNS can bypass internal filtering if you’re not careful about which resolvers devices use, for example on separate staff and guest VLANs.

Why Knowing How DNS Works Matters to a Business Owner

I sometimes get pushback from clients who say this all sounds like an IT problem. It is, until it becomes a revenue problem.

Think about what rides on your domain name: the website, customer email, booking or payment systems, Microsoft 365 or Google Workspace sign in, and API endpoints if you sell software. When DNS fails, all of those fail together, and usually in a way that looks like everything else is broken.

DNS also affects speed. Every new domain a web page pulls from, such as analytics scripts, fonts, chat widgets, and ad tags, needs its own lookup. A slow resolver or a poorly chosen authoritative provider adds delay to each one. For an online business, those milliseconds add up in bounce rates and conversions. Managed DNS providers with global anycast networks generally answer faster because their servers sit closer to your visitors.

And DNS affects trust. Proper email authentication records decide whether your invoices reach a client’s inbox or their spam folder. That’s a professional reputation issue, not just a technical one.

Putting How DNS Works Into Practice: A Client Checklist

This list turns what you now know about how DNS works into action. When I onboard a new organization, I run through it before I touch anything else, and it belongs in any small business network setup:

  • Confirm who owns the domain account, and that it isn’t tied to a former employee’s personal email.
  • Turn on auto renew and verify the payment method.
  • Enable multi factor authentication on the registrar and DNS provider.
  • Ask the registrar about registry lock for critical domains.
  • Document every record in the zone and what it’s for.
  • Check that SPF, DKIM, and DMARC are in place and passing.
  • Enable DNSSEC if the provider supports it cleanly.
  • Review TTLs and lower them ahead of any planned migration.
  • Consider a secondary DNS provider for business critical domains.
  • Set up external monitoring that alerts you if your main records stop resolving.

None of these take long. Together, they prevent the majority of DNS incidents I’ve been called in to fix. If nobody on staff owns these tasks, they are a standard part of most managed IT services agreements.

Final Thoughts on How DNS Works

Understanding how DNS works won’t make you a network engineer overnight, and it doesn’t need to. What it gives you is the ability to ask the right questions when something breaks, and to put a few simple protections in place before it does.

The system itself is a small marvel. A query leaves your laptop, bounces through a resolver, gets pointed from the root to a TLD to an authoritative server, and returns with an answer, often in less time than it takes to blink. It does this without any single owner, across thousands of servers run by organizations on every continent. Forty years after its original design, it still scales to the entire planet.

So the next time a site won’t load and everything else looks fine, remember the old line from that senior engineer of mine. Check DNS. Then check it again.

Frequently Asked Questions

Can you explain how DNS works in simple terms?

DNS is the internet’s naming system. It converts a domain name like example.com into the numeric IP address computers use to connect. See Cloudflare: What is DNS?

How long does a DNS change take to work?

It depends on the TTL of the old record. Resolvers keep cached answers until the TTL expires, which can range from a few minutes to a couple of days. See Cloudflare: What is TTL?

Are there really only 13 root servers?

No. There are 13 root server identities, but thousands of physical servers share those addresses through anycast routing. See the ICANN RSSAC FAQ.

Who operates the DNS root servers?

Twelve independent organizations, including Verisign, ICANN, NASA, RIPE NCC, and the WIDE Project, operate the 13 root identities. See IANA: Root Servers.

What is the difference between a recursive resolver and an authoritative server?

A recursive resolver hunts for answers on your behalf. An authoritative server holds the actual records for a domain and gives the final answer. See Cloudflare: DNS Server Types.

What is DNSSEC and do I need it?

DNSSEC adds digital signatures to DNS records so resolvers can confirm answers weren’t tampered with. It’s strongly recommended for business domains. See ICANN: DNSSEC, What Is It and Why Is It Important?

What is DNS over HTTPS?

DNS over HTTPS encrypts DNS queries inside regular HTTPS traffic, protecting lookups from being viewed or altered on the network. See IETF RFC 8484.

Why does my website work but my email doesn’t?

Website traffic follows A or CNAME records, while email follows MX records. If the MX records are wrong or missing, email fails even when the site loads fine. See Cloudflare: What is a DNS MX Record?

References

Tags: