On Thu, Mar 26, 2015 at 12:17 PM, Matus UHLAR - fantomas <uh...@fantomas.sk> wrote: > On 26.03.15 11:34, Frank Even wrote: >> >> Zone files were in place for the necessary domains, but were outdated >> (assuming one of our updates broke something somewhere, they were all >> on average 3 months old). > > >> Here is where the issue is. I've generally found if BIND fails to >> write the zone, it generally loads it into memory (masking the fact >> that there is an issue here for an extended period of time). 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? > > > What's the SOA? It's possible that the zones were not expired, so they were > provided as saved on disk. Since BIND wasn't able to transfer newer > versions, it continued providing old versions. >
Yes, the old versions were provided on disk on initial load. But that was then followed up with a SUCCESSFUL zone transfer minutes later, but the server was unable to save the tmp file in the working directory and served stale content until about 2 hours later when the server was able to get another successful zone transfer from the master and then loaded the new zone in memory (despite being unable to write the tmp file to update the local copy of the zone). _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
