send: socket is not connected

[Muzinich, Mike]

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 <bind-users-bounces at lists.isc.org> on behalf of Ben Scott <bscott at isc.org>
Organization: Internet Systems Corporation
Date: Thursday, July 9, 2026 at 1:22 PM
To: "bind-users at lists.isc.org" <bind-users at lists.isc.org>
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20260709/22d66c03/attachment-0001.htm>