A negative DNS answer has a type and a lifetime
Follow recursive resolution, distinguish NXDOMAIN from NODATA, and calculate negative-cache lifetimes without confusing DNS TTL with packet hop limits.
On this page
The question for today
What you’ll understand
- Distinguish authoritative data from recursive and local cached answers.
- Explain name nonexistence versus absence of one requested record type.
- Calculate an RFC 2308 negative-cache lifetime from SOA fields.
An application normally begins with a name, while forwarding needs an address. DNS resolution connects those layers through delegation, authoritative data, and caches. A negative answer is not simply an absence of bytes: it can say that a name does not exist or that the name exists without the requested record type. It can also remain cached after an operator publishes new data. Understanding the type and remaining lifetime of that evidence prevents a routing investigation from chasing a failure that occurs before any service packet is sent.
Follow the answer's authority and cache boundary
A stub resolver typically asks a recursive resolver, which obtains answers using cached data or queries following DNS delegation. Authoritative servers provide data for their zones; recursive resolvers can return cached copies with remaining lifetimes. The exact query name, class, record type, response code, and authority information matter. Asking for A and asking for AAAA are different questions. A working IPv4 answer does not prove that an IPv6 record exists, and a correct DNS answer does not prove that its address is routed or the application is healthy.
Compare a recursive answer with an appropriate authoritative answer when investigating stale or negative results. Different recursive resolvers and application-local caches can hold different remaining lifetimes because they learned data at different times. A changed authoritative record does not instantly invalidate all ordinary caches. Capture the response actually used by the application rather than assuming that a command run against a different resolver sees identical state. Also distinguish a timeout or server failure from an authoritative negative answer; they imply different evidence and caching behavior.
NXDOMAIN and NODATA answer different questions
NXDOMAIN indicates name nonexistence at the name whose resolution failed; after following a CNAME alias, that can be the target rather than the original queried owner. NODATA is a useful term for a negative answer in which the name exists but the requested record type does not, normally with a NOERROR response code and the appropriate authority evidence. A name can have an A record while lacking AAAA. Treating that AAAA NODATA response as proof that the whole name is absent can suppress a valid IPv4 lookup and create an application failure unrelated to packet routing.
RFC 2308 makes the negative-cache lifetime depend on the smaller of the SOA record's TTL and its MINIMUM field in the authoritative negative response. It also specifies distinct cache keys for name errors and type-specific absence. A resolver may impose additional policy bounds, so the RFC calculation describes the supplied negative lifetime rather than every implementation's final retained duration. Inspect the SOA evidence and remaining TTL instead of assuming a zone's positive A-record TTL controls an already cached NXDOMAIN answer.
Cache repair changes future observations over time
Suppose a deployment accidentally queries a name before creating it and receives a cacheable negative response. Publishing the record afterward fixes authoritative data but leaves clients behind negative caches waiting until expiry or an authorized cache action. Repeating the application request faster usually reuses the same negative evidence rather than forcing a fresh authoritative lookup. Design rollouts to publish necessary DNS data in advance, verify the relevant resolver paths, and distinguish expiry-based propagation from transport reachability once an address becomes visible.
The queue lab highlights why disabling useful caching can move pressure to resolution services. Interpret λ and μ as incoming and completed lookup work in a simplified fluid model. For each separate load comparison, press Reset, set both desired rates, predict backlog growth or drainage from the initial four items, then Play or Step. The lab has no DNS messages, delegation graph, TTL countdown, or negative-answer types. Its separate stochastic residence-time formula has assumptions that DNS traffic may violate. Use it to motivate measured cache-hit and upstream-query rates, while actual DNS responses establish whether a failure is NXDOMAIN, NODATA, or a resolution error.
Work it through
Time a cached negative answer
At 12:00:00 a resolver receives a cacheable NXDOMAIN with SOA TTL 600 seconds and SOA MINIMUM 180 seconds. The authoritative record is created at 12:00:30. Assume no refresh or extra policy cap.
Take the smaller SOA value: min(600, 180) = 180 seconds. The negative entry learned at noon expires at 12:03:00 under the stated simple cache behavior.
Creating the record thirty seconds later does not automatically purge that resolver's entry. At 12:01:10, seventy seconds have elapsed since caching, so 180 − 70 = 110 seconds remain.
After expiry, a fresh successful lookup can learn the new record. Other resolvers may differ because they learned negative data at another time or apply different policy limits.
The authoritative fix at 12:00:30 can coexist with this resolver returning its cached negative answer until 12:03:00. The modeled remaining lifetime at 12:01:10 is 110 seconds.
The living notebook
Explore the model
Interactive lab · queue
Caching changes resolution work, not route selection
For each fresh lookup-work comparison, press Reset, set both arrival λ and service μ, predict the normalized backlog trend from four initial items, then Play or Step. The fluid model has no DNS hierarchy, cache entries, TTLs, or NXDOMAIN semantics and cannot calculate authoritative propagation.
- Fluid backlog
- 4
- Net rate · λ − μ
- −1 /s
- M/M/1 mean residence
- 1 s
Fluid backlog starts at 4 and follows max(0, 4 + (λ − μ)t). The separate M/M/1 residence-time formula assumes Poisson arrivals, exponential service and λ < μ. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forNegative-answer evidence needs inspection at the DNS layer; lookup-service capacity and packet routing answer different questions.
Pause & reason
Check your understanding
Your turn
Try it yourself
An authoritative negative response contains SOA TTL 900 seconds and MINIMUM 300 seconds. A resolver learns it at t=0. Under a simple countdown with no refresh or extra cap, what remains at t=125 seconds, and does lowering a newly added A record's TTL purge it?
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
First determine the original negative lifetime using the smaller SOA quantity, then subtract elapsed time. The negative entry was learned before the A record existed.
Compare with the solution
The supplied negative lifetime is min(900, 300) = 300 seconds. At 125 seconds the simple remaining lifetime is 175 seconds. Lowering the new positive A record's TTL does not retroactively purge the existing negative entry; it affects positive answers learned under that data. Check the actual resolver and application cache, since implementation policy can shorten or otherwise change retention behavior.
Keep the idea
Take it with you
- Recursive, authoritative, and local application answers can reflect different cache states.
- NXDOMAIN describes name nonexistence; NODATA describes absence of a requested type.
- Negative-cache lifetime uses the SOA values and is separate from packet hop limits.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.