loss of masters over ipsec hoses bind

[Barry Margolin]

In article <fkh44f$199f$1 at sf1.isc.org>,
 "Matt LaPlante" <cyberdog3k at gmail.com> wrote:

> I'm currently running Bind 9.4.1 (Ubuntu Gutsy).  I have several zones
> in master->slave setups, which normally works just fine.  The other
> day, however, I ran into an odd problem.  A couple of the slave zones
> generally update over an ipsec connected network.  The ipsec
> connection went away, and shortly thereafter bind royally wedged
> itself, refusing to serve any data (including basic forward lookups)
> and was not even responding to rndc restarts.  It took me a good while
> of restarting the system and poking around logs to decide to strace
> the process, which eventually lead me to removing the ipsec-dependant
> slave zones from the config.  As soon as I did this, Bind became
> stable again.  Interestingly, zones which updated over public IP space
> behaved fine, even if the master server was unreachable.  It was only
> zones that were trying to go over the down ipsec connection that hosed
> the daemon.
> 
> This whole issue is logged in a bit more detail here, including output
> from strace:
> https://bugs.launchpad.net/ubuntu/+source/bind/+bug/177489
> 
> I can (apparently) reproduce this issue again with little difficulty,
> so I'd be glad to help debug it.
> 
> -
> Matt LaPlante

I'm having a hard time imagining how IPSEC could be impacting this.  
named uses TCP and UDP exclusively, and the underlying connection 
topology should be transparent to it.  Are you sure there aren't some 
configuration differences between the public and private zones, such as 
the refresh and retry intervals?  If the retry intervals are extremely 
short, named could spend all its time retrying the zone transfers after 
a failure.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***