xfrm_larval_drop required for bind over ipsec
Matt LaPlante
cyberdog3k at gmail.com
Mon Apr 21 00:40:21 UTC 2008
On Fri, Apr 18, 2008 at 11:44 AM, Kevin Darcy <kcd at chrysler.com> wrote:
>
> Matt LaPlante wrote:
> > I wanted to follow up on a problem originally reported in this thread
> > [http://marc.info/?t=119826505600004&r=1&w=2]. Running bind 9.4.1,
> > when zone transfers are to happen over an ipsec connection, but the
> > ipsec connection goes away, named effectively stops working on all
> > interfaces.
> >
> > After tracking down a redhat bug that confirmed the issue
> > [https://bugzilla.redhat.com/show_bug.cgi?id=427629] I forwarded the
> > problem on to the lkml, and David Miller quickly suggested the
> > following [http://lkml.org/lkml/2008/4/17/478]:
> >
> > echo "1" >/proc/sys/net/core/xfrm_larval_drop
> >
> > This does appear to fix the issue. The problem is that
> > xfrm_larval_drop defaults to 0 in newer kernels, which apparently
> > causes io over an ipsec connection block when the link is unavailable.
> > It would seem bind, at least as of 9.4.1, does not anticipate this
> > behavior, and hangs rather dramatically in the process.
> >
> Hmmm... how exactly is BIND supposed to "anticipate" that a socket which
> is set to non-blocking will in fact sometimes block, if the connection
> is an IPsec one which happens to be in a "larval" state at some
> particular point in time? What should BIND do differently to cope with
> this scenario? Some guidance from the kernel developers and/or IPsec
> gurus might be helpful.
I have no idea. I'm not a kernel developer, so I have no clue what
they expect to be happening at the application level. It has been
brought up once before (that I could find) where someone suggested
making the default behavior the one suggested here, but it was
rejected for reasons that are unclear to me. Thread here:
http://lkml.org/lkml/2007/12/4/260
>
> For some odd reason, "larval" makes me think of "bug". But maybe that's
> just me...
Not just you. :)
>
>
> - Kevin
>
>
>
>
More information about the bind-users
mailing list