DNS Resolution — Networking

Recursive vs. iterative queries

Your OS makes a recursive query to its configured resolver: "give me the final answer or an error, I don't want to talk to anyone else." The resolver then does the legwork by making a series of iterative queries to root, TLD, and authoritative servers, each of which just says "I don't know, but ask them" until it reaches an authoritative answer.

Domain to resolve

This is a simulated walkthrough of the resolution process, not a live lookup — the answer shown at the end is illustrative.

Common DNS record types

Type	Purpose
A	Maps a name to an IPv4 address. What this page's demo is simulating.
AAAA	Maps a name to an IPv6 address.
CNAME	"Canonical Name" — an alias pointing one name to another name, e.g. www.example.com → example.com, which is then looked up in turn.
MX	"Mail Exchange" — which mail server should receive email for this domain, with a priority for failover.
TXT	Arbitrary text, commonly used for domain-ownership verification and email anti-spoofing records like SPF.
NS	"Name Server" — declares which servers are authoritative for this domain. This is exactly what the TLD referral hands back in the walkthrough above.
SOA	"Start of Authority" — metadata about the zone itself: the primary name server, an admin contact, and several timers — including the negative-caching TTL described below.

TTL: who sets it, and where negative caching lives

Every record's TTL is set at the authoritative source, by whoever administers the zone — it travels with the answer through every cache along the way. Different record types for the same name often carry completely different TTLs:

Record	Typical TTL	Why
A (example.com)	300s	Might need to fail over to a new server quickly
MX (example.com)	3600s	The mail server rarely changes
NS (example.com)	86400s	Who's authoritative almost never changes

Negative answers — NXDOMAIN, or "no record of this type" — get cached too, but their duration comes from a different place entirely: the zone's SOA record's minimum field (per RFC 2308), not any individual record's own TTL.

TTL also doesn't travel back in time: every cache layer — resolver, OS, browser — stores its own "expires at" timestamp from the moment it first cached the answer. There's no push notification when a record changes; each layer just independently notices its copy is stale once its own timer runs out. That's what "propagation" actually is: independent timers expiring at different moments, not a wave moving outward. It's why the standard move before migrating a record is lowering its TTL a day or two ahead of cutover, so every cache has already rolled over to the short TTL by the time the real change happens.

OS-level caching differs by platform

Once an answer leaves the resolver, whether — and how — it gets cached again on your own machine depends entirely on the operating system:

OS	Built-in caching?	Inspect / flush
Windows	Yes — the DNS Client service, honoring the response's real TTL	ipconfig /displaydns · ipconfig /flushdns
macOS	Yes — via mDNSResponder, also honoring the real TTL	dscacheutil -flushcache
Linux	No, not by default — glibc's resolver caches nothing at all; only a local daemon like systemd-resolved, nscd, or dnsmasq caches, if one happens to be running	resolvectl flush-caches

This is why the same lookup can behave differently right next to each other: a Linux box with no local caching daemon re-queries fresh every time, while a Windows machine beside it can keep confidently serving an answer it cached ten minutes ago.

The hosts file: no DNS, no TTL, no caching

The hosts file is a fundamentally different mechanism from everything else on this page. On Linux and macOS, the resolution order itself — typically the hosts: files dns line in /etc/nsswitch.conf — checks the hosts file first. If a name matches there:

No DNS query is sent at all — TTL never enters the picture, because DNS itself is never consulted.
The entry never expires on its own — it's a static mapping that only changes when someone edits the file.
It's purely local to that one machine — never distributed, never cached anywhere downstream.

This is exactly why editing your hosts file is the standard trick for testing a site against a new server before an actual DNS cutover — it sidesteps TTL and caching entirely. It's also a classic troubleshooting trap: someone updates DNS, waits out the TTL, and still gets the old answer, because a stale hosts file entry was winning the whole time and DNS was never even queried.

Common gotchas

Low TTLs aren't free. A short TTL makes DNS changes (like failing over to a new server) take effect faster, but it also means every resolver has to re-query more often — a tradeoff between agility and load.
"Propagation delay" is really just caching. There's no global push of DNS updates — every resolver only refreshes its own cached copy once that record's TTL expires, which is why the same change can appear at different times to different users.
NXDOMAIN gets cached too. If you query a typo'd domain, resolvers remember "this doesn't exist" for a while, so fixing a real typo and re-querying immediately can still show the old failure until that negative cache expires.
Plain DNS queries aren't encrypted by default. Anyone on the network path can see which domains you're resolving. DoH/DoT address this by encrypting the query itself. See the DNS Security page for how that differs from DNSSEC, and how the resolution process above can be attacked directly.