IND 9.20.24 - stale-answer-client-timeout 0 triggers excessive authoritative queries before TTL expiry

[fitwateys]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20260707/6fbbefa8/attachment.htm>