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.
