send: socket is not connected

[Ben Scott]

[Clerical note: This message is an on-list reply to an off-list reply. 
My error resulted in the conversation accidentally being moved off-list. 
  Which Mike's permission, I am returning the conversation to the list, 
so others can contribute and/or benefit.]

On 7/9/26 14:51, Mike Muzinich wrote:
> All DNS servers are running Red Hat Enterprise Linux release 8.10 with 
> RedHat’s bind-9.11.36-16.el8_10.8.x86_64 package.

   This complicates things.  ISC BIND 9.11.16 was released in 2021, and 
BIND 9.11.0 was released in 2016.  The overall branch is around ten 
years old at this point.  A huge number of improvements and bug fixes 
have landed in ISC BIND since then.

   Further, Red Hat has been making their own changes to the software 
since them.  Some of that is backporting fixes from newer BIND releases. 
  Some of it is implementing their own fixes, independently.  And I 
expect they have also been tuning things to work as well as possible 
with RHEL.  One of the great things about open source is that vendors 
can do things like that -- modify software to better fit their 
customers' needs.  But it does mean that we here at ISC are no longer in 
the best position to help.  If you need help with Red Hat's software, 
your best bet is to contact Red Hat.

   Our typical recommendation, for people who want to venture outside of 
the Red Hat ecosystem, is to install a current version of vanilla ISC 
BIND.  This gets you the latest BIND features and fixes, while still 
preserving your investment in the Red Hat platform.  You can find 
packages built for RHEL 8 here:

https://copr.fedorainfracloud.org/coprs/isc/bind/

On 7/9/26 14:51, Mike Muzinich wrote:
> I am going to install and configure BIND on another server on the same
 > subnet to see if I can duplicate this.  Very odd.

   That will help narrow things down.  If it works then, you know the 
problem is likely between the local network and the far-end secondary 
server.  If it still fails, the problem is likely in the local switch 
and/or the primary server itself.

   It is likely that examination of logs and/or packet captures will be 
required to pin it down further, however.

   Good luck, and please keep us posted on what you find.

   -- Ben

-- 
Any opinions expressed in this message are those of the author alone.
All information is provided without warranty of any kind.