@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" <[email protected]> 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) [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 24. 3. 2026, at 8:37, fitwateys <[email protected]> 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ý" <[email protected]> wrote: >Hi, > >what does dns.sys.srvtest. return? > >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 24. 3. 2026, at 6:47, fitwateys <[email protected]> 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.
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
