DNS still returns NXDOMAIN. How long can a missing name stay cached?
You added the record, but some visitors still cannot open the site. Compare DNS responses to see whether their resolver is using an older negative answer.
Before launching a new subdomain, you look it up and get NXDOMAIN. A moment later, you add an A record. The authoritative server now returns the right address, but the site is still unreachable from the same network. The recursive resolver may have cached the earlier answer saying the name did not exist. To confirm it, check the answer from the resolver the affected client uses.
Distinguish a missing name, a missing record type and a resolution failure
NXDOMAIN means DNS reported that a name does not exist. In a CNAME chain, it may refer to the final target. When a name exists but the requested record type is absent, the response may show NOERROR, an empty ANSWER section and an SOA record in AUTHORITY. This is called NODATA. For example, a name can have an A record while an AAAA lookup returns NODATA.
A resolver can reuse a cached NXDOMAIN answer for other record types at the same name and class. NODATA is cached for the specific type. SERVFAIL reports a resolution failure, which can happen during DNSSEC validation, for example. A resolver can cache this failure temporarily too. The response leaves the existence of the name unresolved.
Run the same query against two servers
Use dig @192.0.2.54 api.example.com. A to query the user's resolver. Then use dig @192.0.2.53 api.example.com. A +norecurse to query an authoritative server directly. The name and addresses are examples. Substitute the affected name and the actual server addresses. If the browser uses a separate DNS over HTTPS resolver, check that path as well.
Record the time, server address, response code, and the ANSWER and AUTHORITY sections. Check the aa flag in the direct response and compare all delegated authoritative servers where needed. If they disagree, investigate how the zone was published. If they agree on the correct address while the affected resolver returns NXDOMAIN with an SOA record, a falling SOA TTL on repeat queries supports the cached-answer explanation.
Use the SOA TTL to estimate when to check again
For a negative answer, the authoritative server compares the SOA record's TTL with its MINIMUM field and uses the lower value. With a TTL of 3600 seconds and a MINIMUM of 900 seconds, the resolver can cache that answer for up to 900 seconds. If the SOA TTL in the resolver's negative answer is now 180, check again in about three minutes. Other resolvers may have different time remaining.
Lowering the new A record's TTL leaves the cached NXDOMAIN entry with its original lifetime. If you manage the affected resolver, you can clear the relevant cache entry following its documentation once you have checked the authoritative answers. Clearing a laptop's DNS cache helps only when that layer holds the old answer. The laptop can fetch it again if its resolver still returns it.
Confirm recovery from the network that saw the failure
Repeat the lookup through the original resolver, then test HTTPS using the actual service hostname from the same network. Check the certificate and the operation the visitor needs to complete. If DNS now resolves and HTTPS fails, investigate the connection or application.
Before the next launch, publish the records in advance. If clients may have queried the name before the change, allow time for cached negative answers to expire. Record which resolver answered each check and whether it returned NXDOMAIN, NODATA or a resolution failure. With that information, you can repeat the same test when another report comes in.
- Record the exact name, query type and resolver.
- Check that the authoritative servers agree.
- For a negative answer, check the remaining SOA TTL.
- Confirm DNS resolution and HTTPS from the affected network.
What to take away
Once the record is in the zone, check what the user's resolver still returns. The remaining TTL in a negative answer helps you time the next check. Confirm recovery by resolving the name and testing the service over HTTPS.
