I wonder if this is the same problem we are experiencing after upgrading
from 9.4.2 to 9.5.0. Win2K and W2K3. Do you see any memory problems with the
named process when this happens? Our named grows until the memory and
virtual memory is exhausted, and stops responding to queries. Restarting the
service "solves" the problem. For few days.

----- Original Message -----
From: "Vinny Abello"
Sent: Friday, June 27, 2008 6:37 AM
Subject: RE: TCP queries fail - BIND 9.5.0 Windows Server 2003

From: Danny Mayer [mayer@ntp.isc.org]
Sent: Thursday, June 26, 2008 10:20 PM
To: Vinny Abello
Cc: bind-users@isc.org
Subject: Re: TCP queries fail - BIND 9.5.0 Windows Server 2003

Vinny Abello wrote:
> I recently upgraded from BIND 9.4.2 on Windows Server 2003 to BIND

9.5.0. I was troubleshooting an issue today only to track it down to the
fact that my name servers were no longer servicing requests on TCP port
53. UDP queries continued to work without any issues. On one server I
noted in the logs:
> 16-Jun-2008 13:27:30.687 general: .\socket.c:1934: unexpected error:
> 16-Jun-2008 13:27:30.687 general: socket() failed: Invalid argument
> All of my name servers would not respond to TCP queries during my

tests. Eventually I restarted the BIND service on one of my name servers
and everything came back to life and was working properly. I downgraded
back to BIND 9.4.2 for the time being.
> This appears to be a bug from what I can tell. When this was

happening, if I telnet to port 53, the socket connects, but as soon as
any data is sent, the socket is immediately closed. Again, a restart of
BIND seemed to fix it. This is on multiple servers as well.
> Has anyone else seen this? I'm cc'ing bind-bugs to file a bug report.
> -Vinny

What is going on when this happens? Are you doing zone transfers or
something else? If zone transfers, is the from or two the server?


Well, the servers currently (unfortunately) are setup as both recursive
resolvers in addition to being masters and slaves for over 1000 zones, so
they're doing pretty much everything. The primary server that is the master
for almost all the zones also experienced this problems as did the slaves.
We were alerted to the problem when someone with an application that did TCP
based DNS queries said they couldn't resolve anything.