BIND not loading into memory on first transfer

[Frank Even]

On Fri, Mar 27, 2015 at 8:25 AM, Barry Margolin <barmar at alum.mit.edu> wrote:
> 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.

^^^  THIS!  Exactly!  I REALIZE I had a configuration problem that
prevented writing the zone file locally that snuck in as it turns out
on the bind-chroot package update.  That's irrelevant to the issue I
noticed after that. It DOES load up in memory and serve it up
generally.  It's just that what I've seen in this particular instance
is that it failed to do this on the first successful zone transfer,
then loaded it up in memory on the 2nd try (which sadly in this
instance, was 2 hours later due to other issues, which of course
caused it to be noticed in this instance where it might not have been
in previous instances).

Thanks.