How DNS Works (Explained Simply)

DNS (the Domain Name System) turns a name into an IP address. Your OS asks a recursive resolver, which walks the hierarchy (root servers, then the TLD servers, then the domain's authoritative nameserver) and caches each answer for its TTL. That caching is why DNS is fast, and why a changed record can keep serving the old value for hours.

You type example.com, and something has to turn that into an address before a single packet moves. Most of the time this takes milliseconds and you never think about it. Then one day a deploy "works on my machine" but nobody else can reach it, and DNS is suddenly your problem.

The resolution flow, hop by hop

When your browser needs www.example.com, the lookup travels through several layers. Each layer tries to answer from cache before asking the next one.

1. Browser cache: Chrome and Firefox keep their own short-lived DNS cache. If the name was resolved recently, the answer comes straight from memory.
2. OS cache and stub resolver: Your operating system runs a small client called a stub resolver. It checks the OS cache (and files like /etc/hosts), then forwards the query to a configured recursive resolver.
3. Recursive resolver: This is the workhorse, usually run by your ISP or a public provider like Cloudflare's 1.1.1.1 or Google's 8.8.8.8. Its job is to do the legwork and return a final answer. It also caches heavily.
4. Root servers: If the recursive resolver has nothing cached, it starts at the top. Resolvers ship with a hints file listing the 13 root server identities (a through m.root-servers.net); as of October 2026, root-servers.org counts 2,049 anycast instances behind them, run by 12 operators. A root server does not know example.com, but it knows who handles .com and replies with the TLD nameservers.
5. TLD servers: The .com TLD servers do not know the IP either. They know which authoritative nameservers were delegated for example.com and hand those back.
6. Authoritative nameserver: This server holds the real records for the zone. It returns the actual answer, say the A record for www.example.com.

The resolver caches the answer, returns it up the chain, and your browser finally connects. Notice the pattern: the recursive resolver asks around, while each authoritative layer only points one step closer. That distinction, recursive versus authoritative, is the core of DNS. A recursive resolver chases the full answer; an authoritative server speaks only for the zones it owns.

Caching happens at every hop, and how long each answer lives is governed by its TTL.

TTL and why propagation is slow

Every DNS record carries a TTL (time to live) in seconds. When a resolver caches an answer, it honors that TTL before asking again. Set a TTL of 3600 and resolvers around the world may serve the old value for up to an hour after you change it.

This is what people mean by "DNS propagation." Nothing is actively pushed. The old value simply ages out of caches at its own pace. If you plan to move a record, lower its TTL to 60 or 300 a day ahead of time, make the change, then raise it back once things are stable. That single habit prevents most migration pain.

The record types you actually use

• A: Maps a name to an IPv4 address. The most common record.
• AAAA: Same idea for IPv6 addresses.
• CNAME: An alias pointing one name at another name. www.example.com might be a CNAME to example.com.
• MX: Mail exchange. Tells sending servers where to deliver email for the domain, with priority values.
• TXT: Free-form text. Used for SPF, DKIM, and domain-ownership verification.
• NS: Nameserver records. They declare which servers are authoritative for a zone and drive delegation.

Inspecting DNS with dig

dig is the tool worth learning. It shows you exactly what the resolver returned, including the TTL. Here is a straightforward lookup:

$ dig example.com A +noall +answer
example.com.        229    IN    A    104.20.23.154
example.com.        229    IN    A    172.66.147.243

Those were example.com's A records in October 2026; they change when the domain changes hosts, which is the point of DNS. The 229 is the remaining TTL in seconds for this cached answer. Run it again a moment later and that number will be lower, counting down toward zero.

To watch the full resolution path from the root down, use +trace. It bypasses your recursive resolver's cache and queries each level itself:

$ dig +trace www.example.com
# output trimmed to one line per hop

.                    IN    NS    a.root-servers.net.
com.                 IN    NS    a.gtld-servers.net.
example.com.         IN    NS    hera.ns.cloudflare.com.
www.example.com.     IN    A     104.20.23.154

Read it top to bottom: root points to .com, .com points to the zone's nameservers, and the authoritative server returns the address. That is the entire flow from the first section, made visible. On Windows, nslookup example.com gives a simpler version of the same answer.

Common real problems

Once you understand caching and TTL, most DNS bugs become recognizable.

Stale cache: You updated a record but still see the old IP. A resolver (or your browser, or the OS) is holding the previous answer until its TTL expires. Flush locally, or query 8.8.8.8 directly with dig @8.8.8.8 example.com to compare against your own resolver.

Wrong or low TTL: A TTL that is too high slows migrations; one that is too low hammers your authoritative servers and can be a fragility risk. Tune it around your change schedule.

CNAME at the apex: A CNAME cannot coexist with any other data (RFC 1912, section 2.4), and the root domain (example.com with no subdomain) must carry NS and SOA records, so a CNAME there is not allowed. This bites teams pointing a bare domain at a load balancer. Providers work around it with ALIAS or ANAME records that resolve the target and serve an A record instead.

Negative caching: "This name does not exist" (NXDOMAIN) gets cached too. RFC 2308 sets that negative-cache TTL to the smaller of the SOA record's MINIMUM field and the SOA's own TTL. Create a record and it may still look missing for a few minutes because the earlier failure is cached.

Split-horizon DNS: The same name returns different answers depending on who asks. Internal clients get a private IP, external clients get a public one. Great for internal services, and a classic source of "works on my machine" confusion when your laptop is on the VPN and CI is not.

Works on my machine: Nearly always a caching or resolver difference. Your machine cached a fresh answer; the other environment still holds a stale one, or uses a different resolver entirely.

Debugging DNS

Work from the outside in. Query an authoritative nameserver directly to see the source of truth, then compare against a public resolver, then your local one. If the authoritative answer is correct but a resolver disagrees, you are looking at a caching or TTL issue and time (or a flush) will fix it. If the authoritative answer itself is wrong, the problem is your zone configuration. Always check the TTL in the output so you know how long a stale value can linger. When the symptom is on a single Linux host rather than everywhere, our DNS troubleshooting on Linux guide covers resolv.conf, systemd-resolved and the local cache layer. For the broader context on how this fits with routing and connectivity, see our networking fundamentals guide.

Questions people ask

How long does DNS propagation take?

As long as the old record's TTL, at most. Nothing is pushed: each resolver keeps its cached answer until the TTL runs out, then asks again. A record with a TTL of 3600 can be stale for up to an hour on any resolver that cached it just before your change. Lower the TTL to 300 a day before a planned change and propagation shrinks to about five minutes.

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

A recursive resolver (your ISP's, 1.1.1.1, 8.8.8.8) does the legwork for clients: it queries root, TLD and authoritative servers in turn and caches the results. An authoritative nameserver holds the actual records for a zone and answers only for that zone. When debugging, the authoritative answer is the source of truth; resolvers can lag behind it.

Why can't I put a CNAME on my root domain?

A CNAME may not share a name with any other record, and the zone apex always has SOA and NS records. Putting a CNAME at example.com would hide them. DNS providers work around this with ALIAS, ANAME or CNAME-flattening records, which look up the target themselves and publish plain A and AAAA records at the apex.

The call we'd make

Lower your TTLs before any planned DNS change, verify with dig against the authoritative server first and a public resolver second, and treat propagation delays as expected rather than broken. DNS rarely fails outright; it just serves an old answer for a while. Once you internalize caching and TTL, the system stops feeling like magic and starts behaving like the predictable, layered lookup it actually is.

Sources

• RFC 1034: Domain Names, Concepts and Facilities
• RFC 2308: Negative Caching of DNS Queries
• RFC 1912: Common DNS Operational and Configuration Errors
• Root Server Technical Operations Association: root-servers.org