TCP fallback does not happen on bind 9.18.11
Summary
After upgrading bind9 from v9.18.10 to v9.18.11, we found that TCP fallback no longer happens. The previous behavior on bind v9.18.10 was that after UDP queries time out, named falls back to TCP. We identified that this change in behavior was introduced by this change !7212 (merged).
BIND version used
v9.18.11
Steps to reproduce
- Block UDP queries.
- Observe that named does not fall back to TCP
What is the current bug behavior?
TCP fallback does not happen after UDP queries time out.
What is the expected correct behavior?
After UDP timeout, named falls back to use TCP.
Relevant configuration files
options {
listen-on { 192.168.4.1; 127.0.0.1; }; # see warning above before changing
version "not currently available";
forwarders {
75.75.75.75;
75.75.76.76;
8.8.8.8;
8.8.4.4;
208.67.222.222;
208.67.220.220;
};
querylog yes;
# Cache and forward
recursion yes;
forward only;
# Enable dnssec
dnssec-validation yes;
auth-nxdomain no; # conform to RFC1035
max-cache-size 2m;
max-cache-ttl 3600;
# Default path is at the root directory, which is not writable by bind.
dump-file "/run/named/named_dump.db";
};
Relevant logs and/or screenshots
This is the packet capture from the working version - v9.18.10. You can see that TCP fallback happens.
Possible fixes
I have not fully traced the code, but TCP fallback might have been happening via the code here? https://gitlab.isc.org/isc-projects/bind9/-/blob/bind-9.18/lib/dns/resolver.c?ref_type=heads#L2600-2625.
With the said commit !7249 (095f634f), this may not happen if the retry counter never gets incremented. I could be wrong on this analysis because I did not carefully trace the code, so please take this with a grain of salt.