IND 9.20.24 - stale-answer-client-timeout 0 triggers excessive authoritative queries before TTL expiry
Ondřej Surý
ondrej at isc.org
Tue Jul 7 05:21:41 UTC 2026
Hi,
if you think there's a bug in BIND 9, please fill an issue in our GitLab and follow the template
that will guide you through the steps needed and ask you for all the material we need to be
able to diagnose and reproduce the issue:
https://gitlab.isc.org/isc-projects/bind9/-/work_items/new?description_template=Bug
Thanks,
Ondrej
--
Ondřej Surý (He/Him)
ondrej at isc.org
ADHD brain at work: I sometimes lose track of my inbox. Please feel free to send a gentle nudge if you're waiting on a reply!
My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.
> On 6. 7. 2026, at 18:39, fitwateys <fitwate at 163.com> wrote:
>
> 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.
More information about the bind-users
mailing list