The servers are running Linux with bind-9.11.X. I was able to replicate the issue on a non-production secondary server. Not sure if I mentioned this but using dig to pull a zone transfer works. Very odd. More to follow.
From: bind-users <[email protected]> on behalf of Ben Scott <[email protected]> Organization: Internet Systems Corporation Date: Thursday, July 9, 2026 at 1:22 PM To: "[email protected]" <[email protected]> Subject: Re: send: socket is not connected CAUTION: This email originated from outside of Los Rios. Do not click links or open attachments unless you recognize the sender and know the content is safe. To mark the message as SPAM, right click the message, select “Junk” , and then select “Block Sender”. [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. -- Visit https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.isc.org%2fmailman%2flistinfo%2fbind-users&c=E,1,b7prjWCRl2Kg1k2ibtOKWF0HqPaHQXSEpwq2abM4XcreUOr3XDqjQJ8Htzdn3GZ-8rmEcRJeIyE_YlKAi-LiN30rwvGD4J9-x2gFMtCLNlIqmu26LA,,&typo=1 to unsubscribe from this list.
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
