# How DNS Works (Explained Simply) URL: https://www.devopsness.com/blog/how-dns-works Author: Kiril Urbonas Published: 2026-08-07 Updated: 2026-10-31 Categories: Infrastructure Tags: DNS, Networking, Infrastructure, Web, DevOps Summary: A developer-friendly walk through DNS resolution, record types, TTL, and the caching quirks that cause real production bugs. --- # 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. > [!VERIFIED] > BIND 9.20.30 (current stable `dig`), against RFC 1034, RFC 2308, RFC 1912 and the root-servers.org operator list. Checked October 2026. 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](/blog/dns-troubleshooting-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](/blog/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](https://www.rfc-editor.org/info/rfc1034/) - [RFC 2308: Negative Caching of DNS Queries](https://www.rfc-editor.org/info/rfc2308/) - [RFC 1912: Common DNS Operational and Configuration Errors](https://www.rfc-editor.org/info/rfc1912/) - [Root Server Technical Operations Association: root-servers.org](https://root-servers.org/)