Hi,
I'm reporting a potential issue observed in BIND 9.20.24 with the
stale-answer-client-timeout option.
Environment:
BIND version: 9.20.24
Role: Caching/forwarding resolver (localdns)
The localdns forwards queries for the sys.srvtest zone to an internal
authoritative DNS server.
TTL for transfer.sys.srvtest: 120 seconds (A record only)
Configuration (related):
stale-answer-enable yes;
stale-cache-enable yes;
stale-answer-client-timeout 0;
zone "sys.srvtest" {
type forward;
forwarders { <internal_auth_ip>; };
};
Observation:
Client queries received by localdns for transfer.sys.srvtest: ~2,700
Queries from localdns to the authoritative server for transfer.sys.srvtest:
~1,200
With a TTL of 120s, the expected authoritative query volume would be roughly
total_queries / 120 ≈ 22. The observed 1,200 is approximately 55x higher than
expected.
After removing stale-answer-client-timeout 0:
Client queries to localdns: ~2,700 (similar traffic)
Queries from localdns to the authoritative server: ~10 (close to expected)
Hypothesis:
The queried name transfer.sys.srvtest only has an A record configured on the
authoritative server. Since clients (e.g. curl) typically send both A and AAAA
queries simultaneously, each client request generates two lookups:
A query: cache hit, served from cache
AAAA query: no record exists, potentially triggering repeated authoritative
lookups
With stale-answer-client-timeout 0, BIND may attempt to refresh stale AAAA
negative cache entries on every query, amplifying the authoritative query
volume. Without this setting, BIND relies on normal negative caching
(max-ncache-ttl), reducing unnecessary authoritative queries.
Question:
Is this expected behavior? I would expect stale-answer-client-timeout 0 to only
affect the stale response timing (return stale immediately vs. wait for
authoritative), not to cause additional authoritative lookups for records with
valid TTLs. Could there be a bug where the stale refresh logic is also
triggered for negative cache entries (NODATA/NXDOMAIN)?
Please let me know if this is a known behavior or if additional debugging
information (query logs, packet captures) would be helpful.--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list.
