Jukka Pakkanen wrote:
> 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.

It is possible. I looked at the code you reported and it's failing to
create the socket using the socket() function so there is little that
named can do. OOM failures would be one way that could happen.


> ----- Original Message -----
> From: "Vinny Abello"
> To:
> Cc:
> 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?
> Danny
> 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.