<div dir="ltr"><div dir="ltr"><div>Hi Greg,</div><div><br></div><div>1. We are considering updating to the latest stable version of BIND, but we need to understand why this is happening, purely out of curiosity.</div><div>2. I agree, here is the configured server. In my opinion, it's pretty standard.</div><div>## Global Named Configuration<br>options {<br> directory "/var/opt/isc/scls/isc-bind/named/data";<br> listen-on { 127.0.0.1; 192.168.41.253; };<br> listen-on-v6 { none; };<br> allow-query {any;};<br> allow-transfer {"none";};<br> dnssec-validation auto;<br> querylog no;<br> recursion yes;<br> recursive-clients 500;<br> dnstap {all;};<br> dnstap-output file "named-logs/dnstap.file";<br> dnstap-identity "ns04.domain.local";<br> deny-answer-addresses { deny-answer-referral-acl; };<br> stale-answer-enable yes;<br> stale-cache-enable yes;<br> max-stale-ttl 12H; <br> stale-answer-ttl 30s;<br> stale-refresh-time 30s;<br> stale-answer-client-timeout 0;<br>};<br><br><br><br>######################<br>#### Clients ACLs ####<br>######################<br><br><br>acl internal-acl {<br> <a href="http://192.168.0.0/16" target="_blank">192.168.0.0/16</a>;<br> <a href="http://10.0.0.0/8" target="_blank">10.0.0.0/8</a>;<br> <a href="http://172.16.0.0/20" target="_blank">172.16.0.0/20</a>;<br>};<br><br>view "internal" {<br> response-policy {<br> zone "some.zone.zone";<br> };<br><br>zone "." IN {<br> type hint;<br> file "named.root";<br>};<br><br>};<br><br></div><div>3. (Mostly AI Generated but should help you through)</div><div><br></div><div>Purpose<br>-------<br>This is a privacy-preserving, text-only excerpt of an actual tcpdump output,<br>prepared for technical discussion on bind-users. It is NOT a raw PCAP and<br>cannot replace the original packet capture for packet-by-packet validation.<br>The observations below were transcribed from a capture taken on the affected<br>resolver. No DNS responses or missing packets were invented.<br><br>Anonymization<br>-------------<br>- 192.0.2.10 = example client address (synthetic; RFC 5737 TEST-NET-1)<br>- 192.0.2.53 = example recursive resolver address (synthetic; TEST-NET-1)<br>- Capture times are elapsed seconds since the first Yahoo client query;<br> absolute timestamps, time zone, host names and interface names are omitted.<br>- All DNS COOKIE byte strings are redacted, but their presence is noted.<br>- Unrelated clients, queries, hostname/organization details and local routes<br> have been removed.<br>- Yahoo authoritative-server IP addresses are retained because they belong<br> to the third party under investigation, not to the reporting organization.<br>- UDP source ports and DNS IDs are retained for correlating the transactions;<br> those values are ephemeral and not host identifiers.<br><br>Selected packets (relative times; RX/TX from the resolver's perspective)<br>------------------------------------------------------------------------<br>T+00.000000 RX UDP <a href="http://192.0.2.10:49218" target="_blank">192.0.2.10:49218</a> -> <a href="http://192.0.2.53:53" target="_blank">192.0.2.53:53</a><br> DNS ID=22524, RD=1, QNAME=<a href="http://yahoo.com" target="_blank">yahoo.com</a>., QTYPE=A<br> EDNS UDPsize=1232, DNS COOKIE present [bytes redacted]<br><br>T+00.001404 TX UDP <a href="http://192.0.2.53:47837" target="_blank">192.0.2.53:47837</a> -> <a href="http://68.142.255.16:53" target="_blank">68.142.255.16:53</a> (<a href="http://ns2.yahoo.com" target="_blank">ns2.yahoo.com</a>)<br> DNS ID=49758, QNAME=<a href="http://yahoo.com" target="_blank">yahoo.com</a>., QTYPE=A<br> EDNS UDPsize=1232, DO=1, DNS COOKIE present [bytes redacted]<br><br> [No matching reply from 68.142.255.16 observed in the capture]<br><br>T+05.518182 TX UDP <a href="http://192.0.2.53:37579" target="_blank">192.0.2.53:37579</a> -> <a href="http://27.123.42.42:53" target="_blank">27.123.42.42:53</a> (<a href="http://ns3.yahoo.com" target="_blank">ns3.yahoo.com</a>)<br> DNS ID=31834, QNAME=<a href="http://yahoo.com" target="_blank">yahoo.com</a>., QTYPE=A<br> EDNS UDPsize=1232, DO=1, DNS COOKIE present [bytes redacted]<br><br> [No matching reply from 27.123.42.42 observed in the capture]<br><br>T+10.001898 TX UDP <a href="http://192.0.2.53:53" target="_blank">192.0.2.53:53</a> -> <a href="http://192.0.2.10:49218" target="_blank">192.0.2.10:49218</a><br> DNS ID=22524, QNAME=<a href="http://yahoo.com" target="_blank">yahoo.com</a>., QTYPE=A<br> RCODE=SERVFAIL, EDNS Extended DNS Error=22<br> EDE 22: No Reachable Authority<br><br>T+10.020380 RX UDP <a href="http://192.0.2.10:49203" target="_blank">192.0.2.10:49203</a> -> <a href="http://192.0.2.53:53" target="_blank">192.0.2.53:53</a><br> DNS ID=48836, RD=1, QNAME=<a href="http://yahoo.com" target="_blank">yahoo.com</a>., QTYPE=AAAA<br> EDNS UDPsize=1232, DNS COOKIE present [bytes redacted]<br><br>T+10.021060 TX UDP <a href="http://192.0.2.53:38359" target="_blank">192.0.2.53:38359</a> -> <a href="http://68.180.131.16:53" target="_blank">68.180.131.16:53</a> (<a href="http://ns1.yahoo.com" target="_blank">ns1.yahoo.com</a>)<br> DNS ID=70, QNAME=<a href="http://yahoo.com" target="_blank">yahoo.com</a>., QTYPE=AAAA<br> EDNS UDPsize=1232, DO=1, DNS COOKIE present [bytes redacted]<br><br>T+15.542790 TX UDP <a href="http://192.0.2.53:37937" target="_blank">192.0.2.53:37937</a> -> <a href="http://98.138.11.157:53" target="_blank">98.138.11.157:53</a> (<a href="http://ns4.yahoo.com" target="_blank">ns4.yahoo.com</a>)<br> DNS ID=59276, QNAME=<a href="http://yahoo.com" target="_blank">yahoo.com</a>., QTYPE=AAAA<br> EDNS UDPsize=1232, DO=1, DNS COOKIE present [bytes redacted]<br><br> [No matching AAAA authoritative replies appear in this excerpt.<br> The capture does not establish the final AAAA client outcome.]<br><br>Corroborating tests from the same resolver host (outside the capture)<br>---------------------------------------------------------------------<br>Several minutes later, direct queries bound to the resolver's same local<br>IPv4 address and sent to <a href="http://ns2.yahoo.com" target="_blank">ns2.yahoo.com</a> (68.142.255.16) succeeded:<br><br> UDP + EDNS + DO + DNS COOKIE : NOERROR, authoritative answer, 77 ms<br> UDP + EDNS + DO, no COOKIE : NOERROR, authoritative answer, 65 ms<br> UDP, no EDNS : NOERROR, authoritative answer, 76 ms<br> TCP + DO : NOERROR, authoritative answer, 77 ms<br><br>The direct tests were performed later than the failed recursive lookup, so<br>these results demonstrate subsequent reachability, not simultaneous success.<br><br>Interpretation and limitations<br>------------------------------<br>- The resolver received a client A query, sent UDP queries to two Yahoo<br> authoritative IPv4 servers, and returned SERVFAIL/EDE 22 after ~10 seconds.<br>- No matching upstream answers to those A transactions were observed at this<br> capture point during that lookup. The packet trace does NOT establish<br> whether responses were lost in the network, filtered, suppressed by an<br> upstream service, or omitted for another reason.<br>- The trace does not demonstrate BIND receiving a valid Yahoo answer and<br> discarding it. It does not prove cache poisoning or a DNS COOKIE defect.<br>- The later successful direct queries make the difference between named's<br> ongoing recursion and independent dig requests worth investigating.<br>- For deeper analysis, the unmodified raw PCAP and contemporaneous resolver<br> debug logs should be retained privately; publishing this text does not<br> disclose the reporting network's actual source or client addresses.<br><br>Questions for maintainers<br>-------------------------<br>1. What resolver/ADB diagnostics would best explain repeated upstream query<br> timeouts for this delegation, while direct dig requests later succeed?<br>2. Are there known BIND 9.20.22 issues involving authoritative-server<br> reachability state, remembered DNS COOKIEs, or query retries?<br>3. Which additional targeted logs or dnstap records would help distinguish<br> genuine network loss from a resolver-specific interoperability issue?<br><br></div><div>Best,</div><div>A.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 27, 2026 at 4:52 PM Greg <<a href="mailto:greg@isc.org" target="_blank">greg@isc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello, Amir.<br>
Firstly, please update to 9.20.30. A lot has happened in the six months since 9.20.22 was released, including many important vulnerability fixes.<br>
<br>
Secondly, please share your config. It's impossible to diagnose an issue without knowing how you have configured the server to behave.<br>
<br>
Lastly, for now, have you captured some packets to see whether you have a network problem somewhere? Fetches timing out and very high SRTT values would suggest poor reachability.<br>
<br>
I hope that helps.<br>
Thanks, Greg</blockquote></div><div><br clear="all"></div><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><table cellpadding="0" cellspacing="0" style="color:rgb(0,0,0);font-family:Verdana;width:420px"><tbody><tr><td height="10"></td></tr><tr><td><table cellpadding="0" cellspacing="0"><tbody><tr height="25" style="vertical-align:middle"><td width="30" style="vertical-align:middle"></td><td style="padding:0px;color:rgb(47,47,48)"><br></td></tr><tr height="25" style="vertical-align:middle"><td width="30" style="vertical-align:middle"><br></td><td style="padding:0px"><br></td></tr><tr height="25" style="vertical-align:middle"><td width="30" style="vertical-align:middle"><br></td><td style="padding:0px"><br></td></tr></tbody></table></td></tr></tbody></table></div></div>
</div>