Support Library
Recursive Resolver Behavior Deep Dive
How recursive resolvers cache, pick servers, validate DNSSEC, fall back to TCP and serve stale data, and how each affects your domain.
The short answer
A recursive resolver does more than follow referrals. It chooses which name server to ask, caches positive and negative answers, minimises what it reveals to each server, validates DNSSEC, retries over TCP when an answer is too large, and may serve stale data when your servers are down. Each of these is a policy choice, so two resolvers can give different answers, or the same answer at different times, for the same name. Knowing the behaviours explains most "it works on one resolver" reports.
Behaviours that change what users see
| Behaviour | What it does | Effect on your domain |
|---|---|---|
| Caching by TTL | Keeps each answer for its TTL, sometimes clamped to a resolver minimum or maximum | Changes reach users only as caches expire |
| Negative caching | Keeps NXDOMAIN and "no such record" answers for the negative TTL from the SOA (RFC 2308) | A record added just after someone looked for it stays invisible for that time |
| Server selection | Tracks response times and prefers the fastest name server, retrying others on timeout | A slow or broken server gets less traffic but still causes occasional delays |
| QNAME minimisation | Sends each server only the labels it needs (RFC 9156) | Better privacy; exposes broken servers that answer wrongly for intermediate names |
| DNSSEC validation | Checks signatures from the root down | A broken chain gives SERVFAIL from validating resolvers only |
| EDNS buffer and TCP fallback | Advertises a UDP size (often 1,232 bytes) and retries over TCP when the reply is truncated | Blocked TCP breaks large answers |
| Serve-stale | Answers from expired cache when authoritative servers cannot be reached (RFC 8767) | Short outages may go unnoticed; removed records can linger |
| Prefetching | Refreshes popular records shortly before they expire | Busy names rarely see a cache miss |
| Aggressive NSEC caching | Uses signed NSEC records to answer for other missing names (RFC 8198) | Fewer queries reach signed zones for names that do not exist |
| Filtering | Blocks names on threat or policy lists | Some resolvers, such as Quad9, return NXDOMAIN for blocked names |
Watching it happen
| Command | What it shows |
|---|---|
| dig @1.1.1.1 example.com A, run twice | The TTL falling between runs: the answer is cached |
| dig @1.1.1.1 nosuchname.example.com A | NXDOMAIN with the SOA in the authority section; its last field and TTL set the negative cache time |
| dig @1.1.1.1 +cd example.com A | The answer with validation turned off, to tell a DNSSEC failure from a server failure |
| dig +trace example.com A | Each referral from the root, as a resolver without a cache would follow them |
What to do on the authoritative side
- Keep every listed name server fast and answering correctly, including for names that do not exist.
- Set the SOA minimum to a sensible negative TTL, commonly 300 to 3,600 seconds. See SOA record tuning.
- Allow DNS over TCP and keep signed responses within the EDNS buffer size where you can.
- Lower TTLs before planned changes rather than relying on resolvers to refetch.
How DNS Panopticon helps
Domain Visualizer asks a public resolver, Cloudflare by default, with the DNSSEC OK bit set, and reads the AD flag to tell whether the resolver validated your zone. Records are shown with the TTL the resolver returned, which may be partly counted down. A second resolver, if you pick one, is compared and differences are reported as resolver variance. Visualizer does not observe resolver internals such as server selection or serve-stale.
Sources and further reading
- RFC 2308: Negative Caching of DNS Queries
- RFC 9156: DNS Query Name Minimisation to Improve Privacy
- RFC 8767: Serving Stale Data to Improve DNS Resiliency
- RFC 8198: Aggressive Use of DNSSEC-Validated Cache
- RFC 7766: DNS Transport over TCP
- Unbound documentation: a widely used open-source recursive resolver