How DNS Works (Explained Simply)

Every web request starts with a question: what IP address sits behind this name? DNS, the Domain Name System, answers it. You type example.com, and something has to turn that into 93.184.216.34 before a single packet moves. Most of the time this happens in a few 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.

This post explains the whole resolution path, the records you actually use, and why DNS changes take longer than you expect.

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. The 13 root server addresses are baked into every resolver. 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.        3212    IN    A    93.184.216.34

The 3212 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

.                    IN    NS    a.root-servers.net.
com.                 IN    NS    a.gtld-servers.net.
example.com.         IN    NS    a.iana-servers.net.
www.example.com.     IN    A     93.184.216.34

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: The spec forbids a CNAME on the root domain (example.com with no subdomain) because the apex must also carry NS and SOA records. 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, governed by the zone's SOA minimum. 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. For the broader context on how this fits with routing and connectivity, see our networking fundamentals guide.

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.