[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://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list.
