Introduction

A migration can briefly remove a DNS record or break delegation, then get repaired quickly while users still see NXDOMAIN for hours afterward. The record may already be back in the authoritative zone, but recursive resolvers and local devices can continue serving the earlier negative answer from cache.

Treat this as a negative-caching problem instead of assuming the record is still missing. Start by comparing the authoritative answer with what affected recursive resolvers return, because restored DNS will not look fixed to users until the earlier NXDOMAIN response expires from the caches they actually use.

Symptoms

  • The domain still returns NXDOMAIN on some networks even after the DNS record was restored
  • Authoritative DNS looks correct, but affected users still cannot resolve the hostname
  • One public resolver works while another still returns NXDOMAIN
  • Mobile data or another office resolves the hostname, but the local ISP or corporate network does not
  • Browser and operating system tests disagree with the authoritative DNS zone during recovery
  • The issue started after a brief missing record, wrong delegation, or rollback during migration

Common Causes

  • A recursive resolver cached the earlier NXDOMAIN response during the migration problem
  • A local operating system, browser, or edge device still holds the negative answer in cache
  • The SOA negative caching timer keeps the restored record hidden until the cache expires
  • An ISP or enterprise resolver refreshes slowly after a temporary DNS failure
  • The record was restored correctly, but affected users continue querying a resolver that cached the outage
  • Validation checked only the authoritative nameserver and missed what recursive resolvers were still serving

Step-by-Step Fix

  1. Query the authoritative nameserver directly and confirm the restored record now exists, because you first need to prove the zone itself is fixed before chasing cache behavior.
  2. Query the affected recursive resolvers and compare their answers with the authoritative result, because the difference shows whether you are dealing with cached NXDOMAIN rather than an ongoing zone problem.
  3. Check the SOA values for the affected zone and note the negative caching window, because that tells you how long resolvers may legally continue serving the old NXDOMAIN result.
  4. Flush the DNS cache on affected endpoints and restart the browser or application making the request, because local negative caching can survive after the recursive resolver has already refreshed.
  5. Test from a different network or with a different public resolver, because that quickly confirms whether the issue is isolated to one resolver cache rather than the restored DNS record itself.
  6. Keep the restored record and delegation stable while caches expire, because repeated DNS changes during recovery make it harder to tell whether you are waiting on cache or creating a new inconsistency.
  7. If business impact is high, use a known-good resolver temporarily for affected clients while the cached NXDOMAIN ages out, because that can restore access without changing the authoritative zone again.
  8. Re-test the exact hostname after the negative cache window passes and confirm the same resolver now returns the restored record, because partial recovery on one network does not prove all impacted users are clear.
  9. Document the outage time, restore time, and resolvers that cached NXDOMAIN, because negative-caching behavior is easy to underestimate during future DNS migrations.