Negative Caching and the SOA Minimum

The SOA minimum field and how its meaning changed

Every zone has one SOA (start of authority) record at its apex. It holds seven fields after the owner name, class and TTL.

In RFC 1035, MINIMUM was described as the minimum TTL for every record in the zone, and many zone tools used it as the default TTL. Implementations disagreed on how to apply it, and RFC 2308 settled the matter in 1998: MINIMUM is now the TTL for negative answers only. Default TTLs for normal records moved to the $TTL directive at the top of the zone file. Older documentation, and some provider control panels, still use the old wording, so it is worth checking which meaning a given tool assumes. REFRESH, RETRY and EXPIRE are covered in SOA Record Tuning.

How a negative answer is built and cached

When an authoritative server returns NXDOMAIN or NODATA, it places the zone's SOA record in the authority section and sets that record's TTL to the smaller of the SOA's own TTL and its MINIMUM field. Resolvers read the negative TTL from there.

The SOA as published: record TTL 3600, MINIMUM 300:

$ dig +noall +answer example.com SOA @ns1.example.com
example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. 2026101501 7200 900 1209600 300

A negative answer carries the SOA with TTL = min(3600, 300) = 300:

$ dig +norecurse +noall +comments +authority new-host.example.com A @ns1.example.com
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2291
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
example.com.  300  IN  SOA  ns1.example.com. hostmaster.example.com. 2026101501 7200 900 1209600 300

What gets cached depends on the kind of negative answer, as explained in NXDOMAIN vs NODATA vs REFUSED:

• NXDOMAIN is cached for the name as a whole. Every record type at that name is treated as missing until the entry expires. Under RFC 8020, resolvers may also treat everything below that name as missing.
• NODATA is cached for that name and type only. A cached "no AAAA for www" does not stop the resolver from answering A queries for www.

Resolvers also apply their own ceiling. BIND, for example, caps negative answers at three hours by default, regardless of what the zone publishes. RFC 2308 itself notes that values of one to three hours work well as a default limit and that values over a day cause problems.

DNSSEC and aggressive negative caching

In a DNSSEC-signed zone, negative answers include NSEC or NSEC3 records that prove which names do not exist. An NSEC record says, in effect, "there are no names between alpha.example.com and delta.example.com". RFC 8198, Aggressive Use of DNSSEC-Validated Cache, lets a validating resolver reuse that proof to answer NXDOMAIN for other names in the same range without asking the authoritative servers again.

That is good for performance and helps blunt floods of queries for random subdomains, but it widens the effect of negative caching. Adding charlie.example.com may not be visible on a validating resolver until the cached NSEC proof covering that range expires. The NSEC records' TTL follows the same negative caching rules, so the SOA values still set the timescale.

The classic incident

The most common negative caching problem is a lookup that happens before a record exists. Automated systems make this easy: a deployment pipeline checks whether app.example.com resolves, a certificate authority validates a challenge record before it is published, or a monitoring probe starts before DNS is ready. Each of those plants an NXDOMAIN in a resolver's cache.

With a MINIMUM of 300, the same mistake would have cost five minutes. The fix is partly configuration and partly process: publish records before anything checks for them, and query the authoritative servers directly when verifying a new name, since they do not cache.

Choosing a negative TTL

A low negative TTL makes new names visible quickly. A high one reduces queries for names that really do not exist, such as typos, scanners, and automated probes, and protects your authoritative servers from repeated lookups of the same missing names. Pick based on how often you create names and how much junk traffic your zone sees.

Because the negative TTL is the lower of the two values, a short TTL on the SOA record itself also shortens negative caching. Keep that in mind if you lower the SOA's TTL for other reasons. When you set the value, set it deliberately: control panels often hide the MINIMUM field or label it "default TTL", which can lead to a very long negative TTL nobody chose. Related TTL trade-offs for positive answers are in DNS TTLs and Caching Explained.

Checking and clearing negative answers

To check a zone's negative TTL, query the SOA and read the last field and the record's TTL, or query a name that does not exist and read the SOA TTL in the authority section. To see what a resolver is holding, query it repeatedly: the SOA TTL in its negative answer counts down like any cached record.

If you run the resolver, you can clear the entry instead of waiting. Common commands include:

BIND: remove a single name from the cache:

$ rndc flushname app.example.com

Unbound: remove all cached negative answers:

$ unbound-control flush_negative

Linux hosts using systemd-resolved: clear the local stub cache:

$ resolvectl flush-caches

You cannot flush caches you do not control, such as an ISP's resolver. For those, the only options are to wait for the negative TTL or to have users switch resolvers temporarily. That is why the value in your SOA matters more than any flushing trick. If SERVFAIL rather than NXDOMAIN is being cached, that is a different mechanism: resolution failures are cached briefly under RFC 2308 and RFC 9520, Negative Caching of DNS Resolution Failures, and the fix lies with the delegation or the servers, not the SOA.

How DNS Panopticon helps

Domain Visualizer checks the SOA record on every scan. It reports when a zone has no SOA record, and flags an SOA that is malformed because it is missing one of the required fields, which include the minimum TTL. The full SOA data is shown in the record details, so you can read the MINIMUM field and the record's TTL together. Keep in mind two separate caches. The public resolvers Visualizer queries may be holding a negative answer for a name you just created, until the negative TTL runs out. Visualizer also saves each scan result, for 24 hours by default, and that saved result does not expire when a DNS TTL does. A result from the cache shows a Cached badge with its age. To check a new name straight away, ask the authoritative servers directly with dig +norecurse @ns1.your-provider.example example.com SOA, using one of your zone's own name servers.

Zone Analyzer shows the configured values from a zone export. SOA rows are hidden or shown with a quick filter pill, which makes it easy to compare the SOA timers across every zone in a multi-zone dump and spot one with an unexpectedly long negative TTL.