send: socket is not connected

[Ben Scott]

[Clerical note: The following message was originally sent 2026 July 08 
at 21:16 UTC.  I meant to send this to the list, but accidentally sent a 
direct reply instead.  Which Mike's permission, I am returning the 
conversation to the list, so others can contribute and/or benefit.]

On 7/8/26 16:52, Muzinich, Mike wrote:
 > The slave shows:
 > failed while receiving responses: connection reset
 > Transfer status: connection reset

   This means the secondary tried to read data from the socket, and the 
OS returned ECONNRESET.  The OS generally does that when TCP gets a 
packet with the RST flag.  That generally happens when the remote host 
received a packet after the socket was closed (by either end).

 > While the master shows:
 > send: socket is not connected

   This means the primary tried to send data to the socket, and the OS 
returned ENOTCONN.  The OS generally does that when the socket was 
closed by something other than the program, or was never connected in 
the first place.  Since the primary is seeing the transfer start 
(otherwise it could not complain about it failing), we know it was 
connected at some point.  So most likely something is causing the 
primary to close the socket.

 > Anybody seen this before?

   Network transport problems are fairly common.  Unfortunately there is 
nowhere near enough information to provide a diagnosis for your specific 
problem.

   Things that might help include:

1. Distribution/OS, OS version, and kernel version, for both servers

2. Version identification of BIND from each server (as given by
"named -v")

3. Relevant config file extracts (any options relating to network, 
network access control, and the zone in question)

4. Log file extracts, from named, for both servers, from during the transfer

5. Consider temporarily increasing the logging level to get more detail. 
  Be aware that increasing logging can have a significant performance 
impact.

6. Check the general system logs for any problems around the same time

7. Check the error counters on the network interfaces and switch ports

8. Check logs and configuration of all firewalls/etc, both on the 
servers themselves, and any intermediate devices

9. If all else fails, perform packet captures of the zone transfer 
attempt, taken from both the primary and secondary, and if possible, an 
intermediate point (router, switch, firewall, etc).  Upload the saved 
packet capture somewhere public, and post the URLs.

   -- Ben

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