BIND not loading into memory on first transfer

[Barry Margolin]

In article <mailman.1821.1427468103.26362.bind-users at lists.isc.org>,
 /dev/rob0 <rob0 at gmx.co.uk> wrote:

> On Thu, Mar 26, 2015 at 11:34:42AM -0700, Frank Even wrote:
> > In this particular instance, the masters ended up under maintenance 
> > shortly after these boxes rebooted, so they were unable to transfer 
> > the zone from them for another 2 hours.  These boxes were serving 
> > stale data after boot despite being able to accomplish one zone 
> > transfer after boot.  It seems that failing the first zone transfer 
> > did NOT load the zone into memory (but subsequent zone transfers 
> > while still failing to write the tmp file DID load the zone into 
> > memory).
> > 
> > I guess the question really is, is this expected behavior or a bug?
> 
> The bug is a misconfiguration bug, where contrary to documented 
> requirements, you have not given named write privilege in its 
> directory.
> 
> I think you're saying named should fail to load the stale zones, 
> which at startup it cannot know are stale.  That does not sound 
> correct to me.
> 
> Perhaps you're suggesting that named should SERVFAIL the zone when 
> the first zone transfer has happened, and while this sounds more 
> reasonable, I am not sure that the zone transfer actually does take 
> place if named is unable to open a temporary file to write.  (What 
> would be the point in talking to the master when you know you are 
> unable to handle the data?)

He's not suggesting either of these. He's saying that when it 
successfully transferred the zone, it should update the in-memory 
version, and serve that, even though it wasn't able to save it to disk. 
That's what it does on the SECOND transfer, it just doesn't do it on the 
FIRST transfer.

-- 
Barry Margolin
Arlington, MA