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)
[email protected]

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 <[email protected]> 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.

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list.

Reply via email to