New DNS Record Still NXDOMAIN: Check Negative Caching

A newly created DNS name can still return NXDOMAIN from a resolver that previously cached its absence. Check the authoritative answer and the resolver's negative response separately. Changing the new record's positive TTL does not retroactively erase an earlier cached negative answer.

RFC 2308 defines negative caching, including how an SOA record supplies the negative response lifetime. This guide focuses on the specific case of a cached absence after creation, not the general idea of DNS propagation or every possible resolver failure.

Confirm the exact name and record type

Write the fully qualified name and requested type before troubleshooting. An accidental extra label or a query for AAAA when only A exists can produce a different result from the one you intended to test.

Use a documentation-only example such as new-service.example.com. Record whether the failure concerns the whole name or one record type. NXDOMAIN indicates a name error; a successful response with no requested data is a different condition that deserves its own interpretation.

Keep application symptoms separate. A browser's “site not found” message is not a complete DNS response. You need the DNS response status, relevant sections, queried resolver, and observation time to test the negative-cache hypothesis.

Verify the authoritative state first

Identify the currently delegated authoritative servers through the approved DNS diagnostic process. Query the exact name and type there, then compare the answer with the intended zone configuration. A saved control-panel form is not proof that every authoritative server serves the new record.

If authoritative servers disagree, investigate publication or zone consistency before blaming a recursive cache. Waiting for a negative cache to expire will not fix a record that is absent from one of the servers responsible for the zone.

Record the answer without unnecessary private information. Public DNS data are often not confidential, but internal names and split-horizon zones can reveal infrastructure. Keep internal resolver testing within the authorized network and avoid exporting that inventory casually.

Inspect the recursive negative response

Compare the same query through the resolver used by the affected client. Look at the response status and the SOA information in the authority section when present. Capture the remaining lifetime shown by the tool instead of assuming it equals the TTL on the newly created record.

The negative-cache lifetime has its own derivation. In the RFC's authoritative response rule, it is bounded by the lesser of the SOA TTL and SOA MINIMUM value. Resolver implementation policies can impose additional behavior, so retain the actual observed result.

Do not label every empty answer NXDOMAIN. A type-specific absence, a server failure, a refused request, and a timeout require different investigations. Collapsing them into “DNS has not updated” makes the diagnostic less accurate.

Use a timeline to test the hypothesis

For an invented case, the resolver cached a negative answer at 10:00 with a 15-minute lifetime. The record was created at 10:03. Seeing the old negative result at 10:05 can be consistent with the remaining cached lifetime; it does not prove the authoritative change failed.

At or after the relevant expiry, query the same name and type through the same resolver again. If it still returns a negative answer, check whether it refreshed from an authoritative server still missing the record or whether another policy is involved.

These times are teaching examples, not a prediction of your resolver's behavior. Avoid repeated rapid queries that do not change the evidence. The key comparison is between authoritative state, cached response lifetime, and a meaningful later observation.

Account for additional client caches

An operating system, application, or browser can have its own cached state. First establish what the recursive resolver currently returns; then investigate the client layer if the application still behaves differently. Do not flush every cache at once and lose the ability to tell which layer mattered.

Use supported cache-management procedures only on systems you administer. A diagnostic workaround that affects shared clients or infrastructure needs the normal change authorization. Clearing a local cache also does not clear a public recursive resolver's cache for everyone.

Test the actual client path after the resolver result becomes correct. A successful command-line lookup does not prove that a long-running process has refreshed its own state or that a connection is reaching the expected endpoint.

Reduce recurrence during planned launches

Publish required names early enough for validation before distributing a new URL. Avoid repeatedly probing a nonexistent future name through production clients when the launch plan can create and verify it first. Keep negative-cache policy changes separate from emergency troubleshooting.

Retain a short incident record with query name, type, authoritative result, recursive result, and timestamps. Text Diff can compare redacted response snapshots, but it does not query DNS or calculate a resolver-specific expiry policy.

Conclusion

When a new name still returns NXDOMAIN, verify who is answering and what was cached. Compare exact authoritative and recursive responses, inspect negative lifetime evidence, and revisit at a meaningful time before changing unrelated TTLs or declaring the zone broken.