Prompt and context
This general technical question tests DNS protocol semantics, caching, and incident diagnosis. A strong answer separates “the name does not exist,” “the name exists but has no requested type,” and “resolution failed,” then explains why fixing authoritative data does not instantly erase an old negative answer from recursive resolvers.
What the interviewer evaluates
- Distinguishing NXDOMAIN from NODATA instead of calling every empty answer “missing DNS.”
- Explaining how SOA data supplies negative-cache timing and how failure caching is bounded.
- Tracing the stub, recursive resolver, and authoritative server path with evidence and remaining TTLs.
- Designing record-creation, rollback, and monitoring procedures without blind cache flushing or retry storms.
Clarifying questions to ask
Confirm the queried name, record type, timestamp, response code, authoritative zone publication state, DNSSEC validation, whether all resolvers or only one network is affected, and whether a local, service-mesh, or application DNS cache is involved.
30-second answer framework
I would query the authoritative server first, then several recursive resolvers while recording NXDOMAIN, NODATA, or SERVFAIL, the SOA in the Authority section, and TTLs. NXDOMAIN says the name does not exist; NODATA says it exists without the requested type, and both can be negatively cached using SOA parameters. If authority is correct but recursion still returns the old answer, wait for the negative TTL or use controlled resolver invalidation; refreshing one client cannot clear upstream caches.
Step-by-step deep answer
1. Separate the negative outcomes
NXDOMAIN means the authoritative chain says the queried name does not exist. NODATA normally has a successful response with an empty answer section, meaning the name exists but lacks the requested RR type. SERVFAIL means the resolution process failed, for example because authority is unreachable or DNSSEC validation failed; it is not proof that the name is absent.
2. Explain where negative lifetimes come from
RFC 2308 allows NXDOMAIN and NODATA responses to carry an SOA. A recursive resolver uses the negative TTL, commonly bounded by the smaller of the SOA MINIMUM and SOA TTL in current implementations, to decide how long to retain the answer. Operators should treat that value as the propagation window for creating or withdrawing records. RFC 9520 also requires bounded negative caching for resolution failures so a transient outage does not block recovery forever.
3. Build a repeatable diagnosis
Run dig @authoritative-server api.example.com A +norecurse to verify the authoritative answer, SOA, and serial, then run the same query against several recursive resolvers. Record status, the Authority section, SOA TTL, and timestamps. Authority-positive plus recursive-NXDOMAIN points to a negative cache or delegation path; NXDOMAIN at authority points to zone publication or naming; SERVFAIL points to reachability, delegation, or DNSSEC.
4. Prevent cache amplification and retry storms
Applications should not busy-loop on a negative answer. Use bounded backoff for service discovery and log response codes with cache age. Publish a new name before production traffic arrives so the first query does not seed many recursive caches with NXDOMAIN. After a change, monitor negative-answer ratios by resolver and region to distinguish an unexpired cache from a continuing authoritative failure.
5. Plan recovery and rollback
You cannot force every public recursive resolver to delete a negative entry immediately. Wait for the negative TTL, clear resolvers you control, repair authority or DNSSEC, and keep an old endpoint or alternate discovery path during the window. Verify authoritative, recursive, and real-request behavior continuously; remove the fallback only after NXDOMAIN and SERVFAIL rates return to baseline.
Model high-quality answer
I separate NXDOMAIN, NODATA, and SERVFAIL first. NXDOMAIN means the name is absent, NODATA means the name exists without the requested type, and SERVFAIL means the resolution chain failed. I query authority for the zone and serial, then compare several recursive resolvers, their response codes, Authority-section SOA, and remaining TTL. A negative answer can remain cached according to the SOA negative TTL, so a newly created record may still look like NXDOMAIN; a resolver may also retain a bounded failure result. I avoid application retry storms, publish names before cutover, use a planned negative-TTL window, and monitor multiple regions and real traffic while retaining a fallback endpoint.
Common mistakes
- Treating NXDOMAIN, NODATA, and SERVFAIL as one empty result.
- Clearing a laptop cache while ignoring recursive-resolver state.
- Assuming editing SOA instantly shortens already stored negative entries.
- Retrying continuously while the authoritative service is still broken.
- Checking only A and forgetting AAAA, delegation, DNSSEC, or spelling.
Follow-up questions and responses
Why does a new A record still return NXDOMAIN?
Confirm that authority has loaded the zone and delegation is correct. If authority returns A, the recursive NXDOMAIN is usually an earlier negative entry; wait for its SOA negative TTL to expire.
Can NODATA delay a later AAAA record?
Yes. A resolver may cache that the name exists without AAAA, so clients can continue seeing an empty answer until that type-specific negative TTL expires.
Can SERVFAIL be cached too?
Yes, modern guidance requires bounded caching of resolution failures, with implementation limits. After repairing authority or DNSSEC, validate with several resolvers while that failure window drains.
Can random subdomains bypass negative caching?
They are not a general fix. Random names add authoritative queries and cache pressure and do not repair delegation, zone, or DNSSEC errors. Fix the authoritative fact and let existing entries expire.