named blocked by zone-transfers

[Andreas Holzhammer]

Solved (sort of):

Unfortunately the "hang" lasted about two hours. I tracked it
down to an interaction of named, syslogd and Linux TCP-SYN cookies.

The slaves send their syslog to the master-server as well. Now
when they got the notifies, a lot of syslog-messages were generated,
which would make the master-server think of being attacked :-(
Either stoping syslogd on the master, disabling syslog-forwarding
from the slave to the master, or disabling TCP-SYN cookies
cured the disease.

I still am not sure about the exact interaction here, but at 
least the immediate problem is solved.

>         There is a known problem where named stops answering while
>         sending out an initial notifies if the original loading
>         takes to long.  This is addressed in an upcoming patch.
>         There could be some additional dead time as named processes
>         queued (in kernel) udp messages.
> 
> > I just had to rebuild our master-nameserver from the tapes...
> > fortunately they were good ;-)
> >
> > Unfortunately we had some work to get named up and running
> > again. It looks like the named-process (bind 8.2.2pl5) on
> > the master was blocked after sending out notifies for all
> > its approx. 300 master-zones to our two secondaries.
> > The slaves are also running bind 8.2.2pl5.
> >
> > the master-nameserver would not resolve any queries, and
> > when I looked at the slave-servers I found two named-xfer
> > processes, which would try to transfer the zones for about
> > one minute.
> >
> > I wonder why the transfers would take so long, as our zones
> > are very short (< 10 records each), and I have enabled
> > transfer-format many-answers.
> >
> > To me it looks like the named-xfer processes just time-out
> > and don't get an answer. I disabled notifies on the master,
> > and all was up and running fine again, but for obvious
> > reasons I would like to enable notifies back again.
> >
> > Any ideas what had happened here, and how to work arround
> > that?
> >
> > The machines are all Linux based, if that matters.