Listen queue overflow

[Vinny_Abello at Dell.com]

In message <FD9B2CB2B33E394FAE3B7466954760571D666C24 at DFWX10HMPTC01.AMER.DELL.CO
M>, Vinny_Abello at Dell.com writes:
> Hi Everyone,
>
> I recently had a recursive server running BIND 9.9.4 on FreeBSD 9.2
> appear to wedge and stop responding to clients. I had a flurry of these
> errors on the console:
>
> sonewconn: pcb 0xfffffe007211d930: Listen queue overflow: 16 already in
> queue awaiting acceptance
>
> I couldn't trace that directly back to the named process by the time I
> looked at it, but I suspect that's what it was since it's really the only
> thing this machine is used for and it stopped working. It seems to have
> oddly become unstuck when I logged into the machine and started looking
> around. I never restarted named. Everything else on the server was
> running normally from what I could tell and no other errors existed that
> I could find. Unfortunately my logs rolled over too fast to check if
> named had logged anything else interesting.
>
> From what I've found in googling, this is an OS level error stating the
> process isn't accepting new TCP connections and it's an application
> fault. I've only ever seen this on this particular machine, and just this
> once. My other recursive servers are running older versions of FreeBSD.

>Or it's just a plain DoS attack.  For any service it is possible to
>send tcp connection requests faster than the service can handle it.

That was my other thought but it went away as soon as I started looking at it, so I have my suspicions.

> Has anyone come across this before and know how to prevent or correct
> this properly?

>You can tune tcp-listen-queue in named.conf.  The current default is 10.

Would it make sense to match this to the default OS value of 16 or is it just an "all depends" type of situation?

> Thanks!
>
> -Vinny
>

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org