DNS resolution and caching: recursion, TTLs and negative answers
Trace a DNS lookup through recursive and authoritative servers. Work through positive and negative caching, TTL changes and why a DNS cutover can succeed for one client and fail for another.
TL;DR: A recursive resolver finds an answer on behalf of a client and can cache it. Authoritative servers publish answers for their zones. A DNS change becomes visible as relevant caches refresh; lowering a TTL at cutover does not erase answers already cached under the old TTL.
Follow a lookup through the right roles
An application usually asks an operating-system resolver interface for an address. The local configuration determines which resolver receives the query, and application or local caches may answer first. A recursive resolver can use cached data or follow referrals toward an authoritative server for the requested name.
A root server points toward the relevant top-level domain. That domain's servers provide a delegation toward the authoritative zone. The authoritative server returns the zone's answer, or a response describing why the requested data is absent. Cached delegation information can skip parts of this walk.
RFC 1034 defines this role separation. The diagram illustrates a cache-miss lookup; actual implementations may have additional forwarding resolvers and local caches.
TTL belongs to the answer already received
At 09:00 a resolver caches api.example.com with a TTL of 3,600 seconds. At 09:10 an operator lowers the authoritative TTL to 60 seconds. The resolver can still retain the old answer until its original lifetime expires. It does not receive an unsolicited correction because the authoritative record changed.
For a planned cutover, lower the TTL far enough ahead to let old cached answers expire, confirm the change, and maintain the old endpoint during the transition. Some clients and intermediate systems impose their own caching behavior, so test the actual client population. A short DNS TTL also does not terminate existing TCP connections to the old address.
| Observation | Explanation to test | Useful next comparison |
|---|---|---|
| Authoritative server shows new address, client sees old | Recursive or local cache retains old answer | Query the client's configured resolver and inspect remaining TTL |
| One office fails, another succeeds | Split DNS, forwarding or distinct caches | Compare resolver addresses and response details |
| New name remains NXDOMAIN | A previous negative response is cached | Inspect negative TTL and the original zone response |
| Address resolves but HTTPS fails | Failure is after DNS | Check connection, certificate name and HTTP routing |
Negative answers are cached too
NXDOMAIN means the queried name does not exist in the relevant DNS view. NODATA is different: the name exists but lacks the requested record type. Negative caching prevents repeated failed lookups from overwhelming the DNS hierarchy, but it can surprise an operator who creates a record immediately after clients queried it.
RFC 2308 defines negative caching and the role of the zone's SOA information in determining the negative answer's lifetime. Treat negative TTL separately from the new A or AAAA record's TTL. Creating a positive record with a short TTL does not directly replace the cached negative response.
Avoid treating every DNS timeout as NXDOMAIN. A timeout, SERVFAIL and an authoritative negative answer indicate different conditions. DNSSEC validation failure, unreachable upstream servers and broken delegation can produce failures even when a record exists in the zone editor.
Inspect the response, then the path
These commands query the reserved example domain and are read-only. They require dig; results depend on the network's resolver and access policy.
dig example.com A
dig example.com AAAA
dig example.com NS
dig +trace example.com
Read the response status, answer section, server used and TTLs. +trace performs an iterative diagnostic walk from the machine running it. It may fail on a corporate network that only permits queries through an approved recursive resolver. Such a failure does not prove the resolver used by the application is broken.
For a real incident, query the affected client's configured recursive resolver explicitly and compare with the authoritative answer for the same name and record type. Preserve the full hostname. A short name can be expanded through search domains into a different question, particularly inside Kubernetes or enterprise networks.
Record types change the interpretation
An A record provides an IPv4 address; AAAA provides IPv6. A CNAME redirects a name lookup to another name, whose own address records and caching also matter. NS records describe delegation. A successful A query says nothing about an IPv6 path a client may prefer after also receiving AAAA records.
In split-horizon DNS, internal and external clients intentionally receive different answers. Using a public resolver to “verify” an internal service may query the wrong view. An enterprise directory can also depend on service-discovery records beyond ordinary address records, so deleting unfamiliar records without understanding their consumers is dangerous.
Work the cutover
An API moves from address A to B at noon. A had a one-hour TTL until noon, when the operator changes both the address and TTL to 30 seconds. Some customers use A at 12:20. Is this proof that their resolver ignored the new TTL?
No. It may be honoring an answer cached before noon. Keep A serving or forwarding compatibly for the planned overlap, inspect observed cache lifetimes and client connection behavior, and use an earlier TTL reduction for the next planned migration. If the old endpoint cannot serve safely, recovery must address those clients rather than assuming the DNS edit is instantaneous.
Practice recursive versus authoritative DNS. Then follow a resolved address through Ingress and gateway routing.