The DNS Field GuideInternet infrastructure, explained

Resolution

How a resolver turns one question into a final answer

The client asks recursively; the resolver usually works iteratively. Cache state determines whether the result needs one local lookup or several network round trips.

Numbered diagram of a DNS lookup from client to recursive resolver, root, TLD and authoritative server
1 Client query2–4 Referrals5 Authoritative answer6 Cached response

Cold-cache walkthrough

Resolving www.example.com A

  1. The stub asks its recursive resolver.

    The RD flag normally requests recursion: return the final result, not a referral.

  2. The resolver asks a root server.

    With QNAME minimisation it asks only what it needs to learn about com, rather than disclosing the complete name immediately.

  3. The root refers the resolver to the com name servers.

    The response contains an NS RRset and usually glue addresses in the Additional section.

  4. The resolver asks a com server about example.com.

    The TLD server returns the delegation for the child zone.

  5. The resolver asks an authoritative server for the actual record.

    The server returns the A RRset, perhaps alongside a DNSSEC signature.

  6. The resolver validates, caches and replies.

    Subsequent clients may be answered directly until the TTL expires.

Caching

TTL is a freshness contract, not a propagation timer

Each RRset has a time to live. A cache counts that value down from the moment it stores the data. Changing a record at the authoritative source does not invalidate copies already cached elsewhere.

Before a planned change, operators often lower the old record’s TTL and wait at least the previous TTL before changing the data. Raising the TTL again can follow after the change has stabilised.

Old data may remain cached untiltime cached + original TTL

Low TTL

Faster changeover, more query traffic and greater dependence on authority availability.

High TTL

Lower load and better resilience to brief outages, but slower recovery from incorrect data.

Serve-stale

Some resolvers can temporarily answer with expired data when authority is unreachable, trading freshness for continuity.

Negative caching

Absence is cacheable data

Resolvers cache authenticated or authoritative evidence that a name or RRset does not exist. This avoids repeatedly asking the same failing question and protects authoritative infrastructure from needless load.

For classic NXDOMAIN and NODATA answers, the negative cache lifetime is derived from the zone’s SOA data. Newer guidance also calls for caching other resolution failures rather than retrying aggressively.

NXDOMAIN and NODATA are different.

NXDOMAIN says the name does not exist. NODATA is a successful response saying the name exists but has no RRset of the requested type.

Selection and resilience

Resolvers continuously judge their upstream paths

Multiple authoritative servers

A resolver measures reachability and response behaviour. It can favour a healthy, low-latency server and move away from failures.

Multiple recursive upstreams

A forwarding resolver may compare answers, latency or validation state depending on implementation. Divergent answers can indicate split DNS, stale caches or an attack.

DNSSEC changes the decision

A fast answer that fails validation is not better than a slower secure answer. Correctness outranks latency.

Practical tracing

Observe each layer separately

Follow delegations
dig +trace www.example.com A
Ask a specific resolver
dig @192.0.2.53 www.example.com A
Inspect authority and additional data
dig example.com NS +norecurse
Request DNSSEC material
dig www.example.com A +dnssec