<div data-ntes="ntes_mail_body_root" style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div id="spnEditorContent"><div style="margin: 0;"><br></div><div style="margin: 0;"><div data-lark-html-role="root"><span class="universal-card-text">Hi,</span><span class="universal-card-text">Follow-up on my original report — I've done additional testing that narrows down the issue further.</span><span class="universal-card-text universal-card-text--bold">New finding:</span><span class="universal-card-text">I tested with a non-existent domain (NXDOMAIN response, cached via SOA minimum = 86400s). With </span><span class="universal-card-code-span"><span class="universal-card-text">stale-answer-client-timeout 0</span></span><span class="universal-card-text">, </span><span class="universal-card-text universal-card-text--bold">every single client query triggers an upstream authoritative lookup</span><span class="universal-card-text">, even though the negative cache TTL hasn't expired.</span><span class="universal-card-text">Test results:</span><br><div class="universal-card-markdown-list"><ul class="universal-card-markdown-list__ul"><li data-marker="0"><div class="universal-card-markdown-list__li-content"><span class="universal-card-text universal-card-text--bold">With </span><span class="universal-card-code-span"><span class="universal-card-text universal-card-text--bold">stale-answer-client-timeout 0</span></span><span class="universal-card-text universal-card-text--bold">:</span><span class="universal-card-text"> client query volume ~2,700, upstream queries </span><span class="universal-card-text">~1,200 (negative cache completely bypassed)</span></div></li></ul><ul class="universal-card-markdown-list__ul"><li data-marker="0"><div class="universal-card-markdown-list__li-content"><span class="universal-card-text universal-card-text--bold">Without </span><span class="universal-card-code-span"><span class="universal-card-text universal-card-text--bold">stale-answer-client-timeout 0</span></span><span class="universal-card-text universal-card-text--bold">:</span><span class="universal-card-text"> same client query volume, upstream queries </span><span class="universal-card-text">~10 (negative cache working correctly)</span></div></li></ul></div><span class="universal-card-text universal-card-text--bold">What this tells us:</span><span class="universal-card-text">The bug isn't limited to stale refresh of expired RRsets. It appears that </span><span class="universal-card-code-span"><span class="universal-card-text">stale-answer-client-timeout 0</span></span><span class="universal-card-text"> causes BIND to treat negative cache entries (NXDOMAIN/NODATA) as stale and refresh them on every query — </span><span class="universal-card-text universal-card-text--bold">even when they are still within their valid TTL</span><span class="universal-card-text"> (SOA minimum field).</span><span class="universal-card-text">This means the stale logic is incorrectly overriding the normal negative caching mechanism entirely, not just providing faster responses for expired entries.</span><span class="universal-card-text universal-card-text--bold">My original hypothesis (A/AAAA amplification) still applies as a secondary factor</span><span class="universal-card-text"> — for names with only A records, the AAAA query returns NODATA (negative cache), which triggers this bug on every curl request. But the root cause is the negative cache bypass, not the A/AAAA mismatch.</span><span class="universal-card-text">Is this a known issue? Would appreciate any guidance on whether this is expected or a confirmed bug.</span><span class="universal-card-text">Best,</span></div></div></div><div style="position:relative;zoom:1"></div><div id="divNeteaseMailCard"></div><div style="margin: 0;"><br></div><pre>[root@test-device01 named]# dig @127.0.0.1 dns1.sys.srvtest <br><br>; <<>> DiG 9.18.21 <<>> @127.0.0.1 dns1.sys.srvtest<br>; (1 server found)<br>;; global options: +cmd<br>;; Got answer:<br>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47867<br>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1<br><br>;; OPT PSEUDOSECTION:<br>; EDNS: version: 0, flags:; udp: 1232<br>; COOKIE: cbe311ad4235cce0010000006a4e0f594102da0ed46e3374 (good)<br>;; QUESTION SECTION:<br>;dns1.sys.srvtest. IN A<br><br>;; AUTHORITY SECTION:<br>srvtest. 600 IN SOA srvtest. root.srvtest. 1783500169 10800 900 604800 86400<br><br>;; Query time: 0 msec<br>;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)<br>;; WHEN: Wed Jul 08 16:50:33 CST 2026<br>;; MSG SIZE rcvd: 110<br><br>[root@test-device01 named]# dig @127.0.0.1 dns1.sys.srvtest <br><br>; <<>> DiG 9.18.21 <<>> @127.0.0.1 dns1.sys.srvtest<br>; (1 server found)<br>;; global options: +cmd<br>;; Got answer:<br>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36488<br>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1<br><br>;; OPT PSEUDOSECTION:<br>; EDNS: version: 0, flags:; udp: 1232<br>; COOKIE: 95fc94bfe6e977c5010000006a4e0f5accdb1ed2e3ab071c (good)<br>;; QUESTION SECTION:<br>;dns1.sys.srvtest. IN A<br><br>;; AUTHORITY SECTION:<br>srvtest. 599 IN SOA srvtest. root.srvtest. 1783500169 10800 900 604800 86400<br><br>;; Query time: 0 msec<br>;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)<br>;; WHEN: Wed Jul 08 16:50:34 CST 2026<br>;; MSG SIZE rcvd: 110<br><br>[root@test-device01 named]# dig @127.0.0.1 dns1.sys.srvtest <br><br>; <<>> DiG 9.18.21 <<>> @127.0.0.1 dns1.sys.srvtest<br>; (1 server found)<br>;; global options: +cmd<br>;; Got answer:<br>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32983<br>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1<br><br>;; OPT PSEUDOSECTION:<br>; EDNS: version: 0, flags:; udp: 1232<br>; COOKIE: 14d340cb98270086010000006a4e0f5a554550dbef818cf7 (good)<br>;; QUESTION SECTION:<br>;dns1.sys.srvtest. IN A<br><br>;; AUTHORITY SECTION:<br>srvtest. 600 IN SOA srvtest. root.srvtest. 1783500169 10800 900 604800 86400<br><br>;; Query time: 0 msec<br>;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)<br>;; WHEN: Wed Jul 08 16:50:34 CST 2026<br>;; MSG SIZE rcvd: 110<br><br>[root@test-device01 named]# dig @127.0.0.1 dns1.sys.srvtest <br><br>; <<>> DiG 9.18.21 <<>> @127.0.0.1 dns1.sys.srvtest<br>; (1 server found)<br>;; global options: +cmd<br>;; Got answer:<br>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30506<br>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1<br><br>;; OPT PSEUDOSECTION:<br>; EDNS: version: 0, flags:; udp: 1232<br>; COOKIE: 35125af12e7b4997010000006a4e0f5b0eba273eeab582a9 (good)<br>;; QUESTION SECTION:<br>;dns1.sys.srvtest. IN A<br><br>;; AUTHORITY SECTION:<br>srvtest. 599 IN SOA srvtest. root.srvtest. 1783500169 10800 900 604800 86400<br><br>;; Query time: 0 msec<br>;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)<br>;; WHEN: Wed Jul 08 16:50:35 CST 2026<br>;; MSG SIZE rcvd: 110<br><br>[root@test-device01 named]# dig @127.0.0.1 dns1.sys.srvtest <br><br>; <<>> DiG 9.18.21 <<>> @127.0.0.1 dns1.sys.srvtest<br>; (1 server found)<br>;; global options: +cmd<br>;; Got answer:<br>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 63975<br>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1<br><br>;; OPT PSEUDOSECTION:<br>; EDNS: version: 0, flags:; udp: 1232<br>; COOKIE: 75e5f275bad1bb11010000006a4e0f5bd589f781fc63596b (good)<br>;; QUESTION SECTION:<br>;dns1.sys.srvtest. IN A<br><br>;; AUTHORITY SECTION:<br>srvtest. 600 IN SOA srvtest. root.srvtest. 1783500169 10800 900 604800 86400<br><br>;; Query time: 1 msec<br>;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)<br>;; WHEN: Wed Jul 08 16:50:35 CST 2026<br>;; MSG SIZE rcvd: 110<br><br>[root@test-device01 named]# dig @127.0.0.1 dns1.sys.srvtest <br><br>; <<>> DiG 9.18.21 <<>> @127.0.0.1 dns1.sys.srvtest<br>; (1 server found)<br>;; global options: +cmd<br>;; Got answer:<br>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5170<br>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1<br><br>;; OPT PSEUDOSECTION:<br>; EDNS: version: 0, flags:; udp: 1232<br>; COOKIE: 0f00ac92fb11f159010000006a4e0f5cea3c30e7d69e3e65 (good)<br>;; QUESTION SECTION:<br>;dns1.sys.srvtest. IN A<br><br>;; AUTHORITY SECTION:<br>srvtest. 599 IN SOA srvtest. root.srvtest. 1783500169 10800 900 604800 86400<br><br>;; Query time: 1 msec<br>;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)<br>;; WHEN: Wed Jul 08 16:50:36 CST 2026<br>;; MSG SIZE rcvd: 110<br><br><br>[root@test-device01 named]# /usr/local/named/bin/dnstap-read /home/named/dnstap |grep dns1.sys.srvtest<br>08-Jul-2026 16:50:31.635 CQ 127.0.0.1:32298 -> 127.0.0.1:53 UDP 53b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:31.062 CQ 127.0.0.1:46438 -> 127.0.0.1:53 UDP 53b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:31.635 CR 127.0.0.1:32298 <- 127.0.0.1:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:31.062 CR 127.0.0.1:46438 <- 127.0.0.1:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:31.635 FQ 0.0.0.0:25022 -> 192.168.11.213:53 UDP 69b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:31.062 FQ 0.0.0.0:27320 -> 192.168.3.69:53 UDP 69b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:31.884 FR 0.0.0.0:25022 <- 192.168.11.213:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:31.299 FR 0.0.0.0:27320 <- 192.168.3.69:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:32.660 CQ 127.0.0.1:46226 -> 127.0.0.1:53 UDP 53b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:32.660 CR 127.0.0.1:46226 <- 127.0.0.1:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:32.661 FQ 0.0.0.0:27291 -> 192.168.3.69:53 UDP 69b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:32.898 FR 0.0.0.0:27291 <- 192.168.3.69:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:33.203 CQ 127.0.0.1:25296 -> 127.0.0.1:53 UDP 53b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:33.684 CQ 127.0.0.1:49147 -> 127.0.0.1:53 UDP 53b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:33.204 CR 127.0.0.1:25296 <- 127.0.0.1:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:33.684 CR 127.0.0.1:49147 <- 127.0.0.1:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:33.204 FQ 0.0.0.0:34713 -> 192.168.3.69:53 UDP 69b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:33.684 FQ 0.0.0.0:60884 -> 192.168.11.213:53 UDP 69b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:33.429 FR 0.0.0.0:34713 <- 192.168.3.69:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:33.933 FR 0.0.0.0:60884 <- 192.168.11.213:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:35.058 CQ 127.0.0.1:21162 -> 127.0.0.1:53 UDP 53b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:34.132 CQ 127.0.0.1:29752 -> 127.0.0.1:53 UDP 53b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:34.596 CQ 127.0.0.1:58008 -> 127.0.0.1:53 UDP 53b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:35.058 CR 127.0.0.1:21162 <- 127.0.0.1:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:34.132 CR 127.0.0.1:29752 <- 127.0.0.1:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:34.596 CR 127.0.0.1:58008 <- 127.0.0.1:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:35.058 FQ 0.0.0.0:63212 -> 192.168.3.69:53 UDP 69b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:34.132 FQ 0.0.0.0:38523 -> 192.168.3.69:53 UDP 69b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:34.596 FQ 0.0.0.0:63821 -> 192.168.3.69:53 UDP 69b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:34.358 FR 0.0.0.0:38523 <- 192.168.3.69:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:34.821 FR 0.0.0.0:63821 <- 192.168.3.69:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:35.284 FR 0.0.0.0:63212 <- 192.168.3.69:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:35.507 CQ 127.0.0.1:62584 -> 127.0.0.1:53 UDP 53b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:36.005 CQ 127.0.0.1:31312 -> 127.0.0.1:53 UDP 53b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:35.507 CR 127.0.0.1:62584 <- 127.0.0.1:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:36.005 CR 127.0.0.1:31312 <- 127.0.0.1:53 UDP 110b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:35.508 FQ 0.0.0.0:52288 -> 192.168.11.213:53 UDP 69b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:36.005 FQ 0.0.0.0:43026 -> 192.168.3.69:53 UDP 69b dns1.sys.srvtest/IN/A<br>08-Jul-2026 16:50:35.752 FR 0.0.0.0:52288 <- 192.168.11.213:53 UDP 110b dns1.sys.srvtest/IN/A<br><div>08-Jul-2026 16:50:36.232 FR 0.0.0.0:43026 <- 192.168.3.69:53 UDP 110b dns1.sys.srvtest/IN/A</div><div><br></div><div><br></div><div><br></div>At 2026-07-07 13:21:41, "Ondřej Surý" <ondrej@isc.org> wrote:
>Hi,
>
>if you think there's a bug in BIND 9, please fill an issue in our GitLab and follow the template
>that will guide you through the steps needed and ask you for all the material we need to be
>able to diagnose and reproduce the issue:
>
>https://gitlab.isc.org/isc-projects/bind9/-/work_items/new?description_template=Bug
>
>Thanks,
>Ondrej
>--
>Ondřej Surý (He/Him)
>ondrej@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 6. 7. 2026, at 18:39, fitwateys <fitwate@163.com> wrote:
>>
>> Hi,
>>
>> I'm reporting a potential issue observed in BIND 9.20.24 with the stale-answer-client-timeout option.
>>
>> Environment:
>> • BIND version: 9.20.24
>> • Role: Caching/forwarding resolver (localdns)
>> • The localdns forwards queries for the sys.srvtest zone to an internal authoritative DNS server.
>> • TTL for transfer.sys.srvtest: 120 seconds (A record only)
>>
>> Configuration (related):
>>
>> stale-answer-enable yes;
>> stale-cache-enable yes;
>> stale-answer-client-timeout 0;zone "sys.srvtest" {
>> type forward;
>> forwarders { <internal_auth_ip>; };
>> };
>>
>> Observation:
>> • Client queries received by localdns for transfer.sys.srvtest: ~2,700
>> • Queries from localdns to the authoritative server for transfer.sys.srvtest: ~1,200
>>
>> With a TTL of 120s, the expected authoritative query volume would be roughly total_queries / 120 ≈ 22. The observed 1,200 is approximately 55x higher than expected.
>>
>> After removing stale-answer-client-timeout 0:
>> • Client queries to localdns: ~2,700 (similar traffic)
>> • Queries from localdns to the authoritative server: ~10 (close to expected)
>>
>> Hypothesis:
>>
>> The queried name transfer.sys.srvtest only has an A record configured on the authoritative server. Since clients (e.g. curl) typically send both A and AAAA queries simultaneously, each client request generates two lookups:
>> • A query: cache hit, served from cache
>> • AAAA query: no record exists, potentially triggering repeated authoritative lookups
>>
>> With stale-answer-client-timeout 0, BIND may attempt to refresh stale AAAA negative cache entries on every query, amplifying the authoritative query volume. Without this setting, BIND relies on normal negative caching (max-ncache-ttl), reducing unnecessary authoritative queries.
>>
>> Question:
>> Is this expected behavior? I would expect stale-answer-client-timeout 0 to only affect the stale response timing (return stale immediately vs. wait for authoritative), not to cause additional authoritative lookups for records with valid TTLs. Could there be a bug where the stale refresh logic is also triggered for negative cache entries (NODATA/NXDOMAIN)?
>>
>> Please let me know if this is a known behavior or if additional debugging information (query logs, packet captures) would be helpful.
>> --
>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
</pre></div>