BIND 9.20.20 Bug Report: stale-answer-client-timeout 0 causes cache not to refresh when A record changes to CNAME

[fitwateys]

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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20260324/8aa3e4c8/attachment-0001.htm>