If someone looked up a name before you created it, their resolver may cache the answer that it does not exist. That negative answer is held for a time set by your zone's SOA record, so a brand new record can stay invisible for a while even though your DNS is correct.
What gets cached
RFC 2308 requires any caching resolver to support negative caching. Two kinds of answers are covered:
- NXDOMAIN. The name does not exist. The resolver caches this against the name and class, so it applies to every record type for that name.
- NODATA. The name exists but has no record of the type asked for. The resolver caches this against the name, type and class.
A negative answer has no record to carry a TTL, so the authoritative server includes the zone's SOA record in the authority section. The negative TTL is the lower of the SOA record's own TTL and the SOA MINIMUM field. RFC 2308 redefines that MINIMUM field to mean the negative response TTL.
A common failure story
You deploy a service, point a monitor at a new hostname before the record exists, then add the record a minute later. The monitor's resolver cached the NXDOMAIN. Your record is live on the authoritative servers, but that resolver keeps answering that the name does not exist until the negative TTL runs out.
The same thing happens with NODATA. You add an AAAA record for a name that only had an A record, and clients behind a resolver that cached the empty AAAA answer keep seeing none.
How to reduce the delay
- Set a sensible SOA MINIMUM. RFC 2308 suggests that resolvers cap negative TTLs, with one to three hours as a sensible default, and warns that values above one day cause problems. Keeping yours low, such as minutes to an hour, makes mistakes cheaper.
- Create records before anything queries them. Do not point health checks, certificate validation or deployment scripts at a name until it resolves from your authoritative servers.
- Check from the authoritative side. Query the zone's name servers directly to confirm the record exists before blaming caches.
- Wait out the SOA value. There is no standard way to flush someone else's resolver, so plan for the delay instead of trying to beat it.
Security notes
The RFC itself points out a denial of service risk: a spoofed NXDOMAIN with a high TTL could make a name appear nonexistent for a long time. That is why resolvers apply sanity limits and why DNSSEC, which provides authenticated denial of existence, matters for high value zones.
Another operational point from the RFC: authoritative servers must include the SOA in NXDOMAIN and NODATA responses so they can be cached, and responses without an SOA should not be cached.
For the TTL side of the same story, read how to plan DNS TTLs before a migration.
Where Safeguard fits
This topic sits below where Safeguard works. Safeguard helps with the application side: scanning dependencies for known vulnerabilities, including in the networking, TLS and HTTP libraries you pull in, and gating pull requests with policies. Start with the free scan at gold.safeguard.sh/scan.
Quick check
Which value sets how long NXDOMAIN is cached?
The lower of the SOA record's own TTL and the SOA MINIMUM field, as defined by RFC 2308.
Is NODATA the same as NXDOMAIN?
No. NXDOMAIN means the name does not exist at all. NODATA means the name exists but has no record of the requested type.
Sources
Last reviewed: 19 October 2026.
