Hi,
I encountered a persistent issue in BIND 9.20.20 where the cache does not
refresh correctly when a domain changes from an A record to a CNAME record, but
only when stale-answer-client-timeout is set to 0.
Environment
BIND Version: 9.20.20
OS: openEuler 24.03 (LTS-SP1)
Architecture: x86_64
Installation: Compiled from source
Configuration
bind
options {
directory "/var/named";
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };
allow-query { any; };
recursion yes;
max-cache-ttl 86400;
min-cache-ttl 3;
stale-cache-enable yes;
max-stale-ttl 90000;
stale-answer-enable yes;
stale-answer-ttl 63;
stale-answer-client-timeout 0; // problematic when set to 0
};
Problem Description
When a domain changes from an A record to a CNAME (e.g., test.sys.srvtest),
BIND continues to return the stale A record from cache instead of refreshing to
obtain the new CNAME.
Before change:
test.sys.srvtest. 120 IN A 127.0.0.130
After change:
test.sys.srvtest. 120 IN CNAME dns.sys.srvtest.
Even after the change, dig test.sys.srvtest returns:
text
test.sys.srvtest. 63 IN A 127.0.0.130 (stale)
with the following EDNS option:
text
EDE: 3 (Stale Answer): (stale data prioritized over lookup)
This issue occurs only when stale-answer-client-timeout 0 is set.
If the line is commented out (default behavior), the cache refreshes correctly
and the CNAME record is returned.
Expected Behavior
With stale-answer-client-timeout 0, BIND should still attempt to refresh the
cache and return the updated CNAME record after the TTL expires, rather than
persistently serving stale A data.
Additional Information
This seems to be a regression or edge case related to how stale answers are
prioritized when the record type changes (A → CNAME) under aggressive
stale-answer-client-timeout settings.
Let me know if you need further details or a test environment.
Thanks!--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list.
