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