concept Domains & DNS
Recursive DNS resolver
Understand recursive DNS resolvers, cache hits and misses, negative caching, and why cached data is not a global clock.
What it means
A recursive DNS resolver accepts a client's request to obtain DNS data and tries to return a useful answer, often following referrals to other DNS servers on a cache miss. It is not inherently authoritative for the name being requested. The resolver may serve a valid cached answer without contacting the authoritative zone again. Your ISP, workplace or a configured third-party provider can operate the resolver; different devices may use different resolvers. Resolver responsibilities Terminology
Try it
Simulation — watch a resolver retain different questions. Query the fixed name/type, repeat it, or advance the virtual clock by 30 seconds. The cache inventory records each fill and expiry; the last answer is kept separate from the controls for your next question.
A resolver’s cache inventory
Query, repeat, advance time, and see which question the cache can answer.
The last answer is shown separately from current inputs. Query again to observe the selected name and type; advancing time alone does not perform a lookup.
| Item | State / result | Why it matters |
|---|---|---|
| Virtual clock | 0 s | Time only moves forward until Reset. |
| Cache | Empty | The first query needs an authoritative result. |
One local resolver, fixed answers and no serve-stale, prefetch, eviction, failure-cache/backoff or DNSSEC validation.
About this model
A and AAAA occupy separate positive/NODATA cache entries. This fixture stores NXDOMAIN by name. Cached entries retain their original expiry when reused. The TTL control applies to subsequent fills only. Failed refresh is not NXDOMAIN. Real resolvers must also cache resolution failures under RFC 9520; this teaching scene omits that cache and retry/backoff behavior. Real negative lifetimes come from the applicable SOA data and policy; this scene uses one explicit chosen lifetime for clarity.
Read the article’s primary sources for protocol rules and implementation-specific limits. This scene has no network access.
Query www.example.test A at t=0, advance to t=30, and query again. The answer comes from cache and still expires at t=60: reading it did not restart the TTL. At t=60 a new query needs a fresh result. Mark the authority unavailable before that query to observe a resolution failure, not a newly invented NXDOMAIN.
Next reset, ask for AAAA at the existing name, and then ask for A. The AAAA NODATA entry does not erase or deny the A RRset. By contrast, missing.example.test produces an NXDOMAIN entry keyed by name in this fixture, so it can answer a subsequent question for a different type at that same absent name. Negative caching distinctions
| Observation | Cache effect | Limit of the conclusion |
|---|---|---|
| Repeated valid hit before expiry | Original expiry is retained | It does not refresh authority |
| AAAA NODATA at an existing name | Stored for that name/type | A may still exist |
| NXDOMAIN at the absent fixture name | Stored as a name-level negative answer | Not the same as a timeout |
| TTL zero | No reusable entry is added | Other records in a real lookup may still be cached |
The chosen lifetime applies to subsequent fills. For simplicity the same control also sets this fixture's negative lifetime; real negative lifetimes depend on SOA data and applicable policy. The scene excludes prefetch, eviction, serve-stale, validation and failure-cache/backoff behavior. RFC 9520 updates RFC 2308 to require caching of resolution failures; repeated failed queries here are individual teaching observations, not a resolver retry policy. Failure caching Reset empties the cache, clears history and restores t=0. Recursive operation Serve-stale is a separate behavior
What a cache can store
| Outcome | What a recursive resolver might reuse |
|---|---|
| Positive answer | A, AAAA or other RRset while its cached lifetime remains |
| Negative answer | NXDOMAIN or absence of a queried type (NODATA), subject to negative caching rules |
| Referral | Delegation data used to find other nameservers |
| Expired but recoverable data | Some implementations may serve stale data under specified failure conditions |
Negative caching matters when a new hostname is created after users previously received NXDOMAIN. The negative response can remain cached with a lifetime derived from the zone's SOA information; it is not simply the prospective new record's TTL. Negative caching
RFC 8767 describes serve-stale behavior, under which a resolver can retain and conditionally answer with expired information to maintain service when fresh DNS lookups encounter difficulties. Do not assume every resolver enables it or that a stale response proves the authoritative zone is outdated. Serve stale
In practice
If one visitor sees an old address and another sees a new one, compare their resolver answers for the same name and type, including TTL and response status. Next query an authoritative nameserver to establish what the zone currently serves. Avoid describing this as a single global propagation process: caches expire independently, configurations differ, and negative/stale replies introduce other possibilities.
The existing DNS TTL model shows one intentionally bounded resolver. See DNS change not visible for diagnosis and authoritative nameserver for the source of zone answers.
Key takeaways
Recursion obtains an answer; caching determines whether a previous answer can be reused. Compare the exact name, type, outcome and saved expiry. Do not mistake a negative answer for a transport failure, and do not assume every cache read extends the lifetime.
Frequently asked questions
Editorial questions, answered from the sources listed for this article.
Can a resolver still answer when the authoritative server is unavailable?
It can reuse an eligible unexpired cached answer. Once a fresh answer is needed, this model reports failure. Some real resolvers implement separately specified serve-stale behavior, which this scene excludes.
Sources & model boundaries
Primary references used for this explanation. The interactive example is an educational model, not a live check.
- RFC 1034 — Domain Names: Concepts and Facilities
Sections 2.4, 3.1, 4.3.2 and 5. DNS tree, zones, referrals, resolvers and caching.
Checked .
- RFC 9499 — DNS Terminology
Sections 2–7. Terminology for authoritative servers, recursion, caching, and delegation.
Checked .
- RFC 2308 — Negative Caching of DNS Queries
Sections 3–6. NXDOMAIN and NODATA negative cache behavior and TTL.
Checked .
- RFC 8767 — Serving Stale Data to Improve DNS Resiliency
Sections 3–7. Conditional stale-answer behavior during authoritative DNS difficulties.
Checked .
- RFC 9520 — Negative Caching of DNS Resolution Failures
Sections 2 and 3.2; updates RFC 2308. Resolution failure is distinct from NXDOMAIN/NODATA; failure caching and retry limits are separate from positive-data lifetime.
Checked .