BIND 9.20.20 Bug Report: stale-answer-client-timeout 0 causes cache not to refresh when A record changes to CNAME
fitwateys
fitwate at 163.com
Wed Mar 25 04:36:40 UTC 2026
@ondrej email account
Thanks, using stale-answer-client-timeout 0 works great, but because of this issue, I have to comment out the configuration and keep the default. Hope it can be fixed soon. Thanks again for your hard work.
At 2026-03-24 19:42:37, "ondrej email account" <ondrej at isc.org> wrote:
OK, this is already tracked as https://gitlab.isc.org/isc-projects/bind9/-/issues/5302
It will get fixed eventually.
--
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 24. 3. 2026, at 8:37, fitwateys <fitwate at 163.com> wrote:
# dig test.sys.srvtest
; <<>> DiG 9.18.21 <<>> test.sys.srvtest
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5353
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 01bd17907fe8581b0100000069c21bbd544b417636a095f2 (good)
;; QUESTION SECTION:
;test.sys.srvtest. IN A
;; ANSWER SECTION:
test.sys.srvtest. 120 IN CNAME dns.sys.srvtest.
dns.sys.srvtest. 56 IN A 10.16.66.188
;; Query time: 17 msec
;; SERVER: 10.187.13.54#53(10.187.13.54) (UDP)
;; WHEN: Tue Mar 24 13:06:05 CST 2026
;; MSG SIZE rcvd: 103
# dig test.sys.srvtest
; <<>> DiG 9.18.21 <<>> test.sys.srvtest
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22381
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 049a5278fe5ebcc50100000069c217f53f30f0e0fd022c17 (good)
; EDE: 3 (Stale Answer): (stale data prioritized over lookup)
;; QUESTION SECTION:
;test.sys.srvtest. IN A
;; ANSWER SECTION:
test.sys.srvtest. 63 IN A 127.0.0.130
;; Query time: 0 msec
;; SERVER: 10.187.13.54#53(10.187.13.54) (UDP)
;; WHEN: Tue Mar 24 12:49:57 CST 2026
;; MSG SIZE rcvd: 125
At 2026-03-24 14:33:49, "Ondřej Surý" <ondrej at isc.org> wrote:
>Hi,
>
>what does dns.sys.srvtest. return?
>
>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 24. 3. 2026, at 6:47, fitwateys <fitwate at 163.com> wrote:
>>
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20260325/9fe7ad75/attachment.htm>
More information about the bind-users
mailing list