A resolver can cache the fact that a DNS name or record type did not exist. If you create the record afterward, users of that resolver may continue receiving the earlier negative answer until its cached lifetime ends.
IN THIS ARTICLE
01 Identify the type of missing answer
NXDOMAIN indicates that the queried name does not exist. A response with NOERROR but no record of the requested type can instead be a no-data answer. For example, a hostname can have an A record while lacking AAAA. These are different from a timeout or SERVFAIL.
For an authoritative negative response, the SOA in the authority section supplies the negative-cache lifetime, based on the lesser of its own TTL and the SOA MINIMUM field. The positive TTL on a newly created A record does not retroactively replace a negative answer already cached elsewhere.
02 Confirm whether caching is the cause
- Query the exact name and type directly against every current authoritative server.
- Confirm that all now return the intended positive answer.
- Compare with the affected recursive resolver and inspect its status and SOA TTL where provided.
- Check whether the earlier lookup concerned a nonexistent parent name or an alias target as well as the visible hostname.
- Wait for the relevant cached negative result to expire, or clear only a cache you are authorised to administer.
03 Example: recognise a cached NXDOMAIN answer
After creating a previously nonexistent hostname, compare your recursive resolver with an actual authoritative server. Replace both example names with your service and authority. Keep the full response so you can see whether the result is NXDOMAIN or an empty answer for one record type.
dig new.example.com A +comments +authority
dig @ns1.example.net new.example.com A +norecurse +comments +answerRead the result: An authoritative A answer alongside a recursive NXDOMAIN can indicate negative caching. The earlier negative response has its own cache lifetime derived from the zone's SOA data. Lowering the newly created A record's TTL does not retroactively clear that earlier cached absence.
Check all authorities before waiting. If one still lacks the name, correct replication first. Also distinguish NXDOMAIN from NOERROR with no A record, which may mean the name exists with a different type. Do not keep deleting and recreating the record while diagnosing its cached result.
Will deleting and recreating the record make it appear faster?
No. Repeating those changes does not clear remote resolver caches and can create new periods of nonexistence. Once authoritative DNS is correct, preserve it while you investigate the specific resolver result.
If authoritative servers still disagree, fix that problem first. If the response is SERVFAIL, investigate DNSSEC, delegation or reachability instead of assuming a negative-cache timer. A public DNS checker can also have its own caching and is not a substitute for the exact query evidence.
How can I avoid this during a launch?
Create and verify necessary names before public tests or application verification repeatedly request them. Plan new hostnames, aliases and validation records ahead of the launch, and allow for negative caching when a service previously did not exist. Lowering unrelated positive-record TTLs will not solve that specific timing issue.