The subject is about the only way I can think to describe a situation we've run into recently. First here is the system:
[root@dns]# cat /etc/redhat-release CentOS release 6.6 (Final) [root@dns]# rpm -q bind bind-9.8.2-0.30.rc1.el6_6.2.x86_64 So, we got bit by a chroot permissions issue (unsure exactly how it got introduced), where the chroot was owned by root, but had named as the group owner. Perms were 750 on the dir (rwxr-x---) 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). We updated some of the boxes, and on restart, named started. It initially started loading the 3 month old zone (one frequently updated I might add). The boxes then did a zone transfer from the master. Failing to be able to write the tmp file to the working directory, it moved on. 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? Thanks, Frank _______________________________________________ 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