'succesful' nsupdate of remote server not persistent across nameserver restart?

Phil Mayers p.mayers at imperial.ac.uk
Sun May 1 18:30:42 UTC 2016


On 01/05/16 19:05, Phil Mayers wrote:
> On 30/04/16 04:49, jasonsu at mail-central.com wrote:
>> Hi
>>
>> On Fri, Apr 29, 2016, at 08:42 PM, Mark Andrews wrote:
>>> Just give it time.  The zone contents are the masterfile + journal.
>>> The masterfile only gets written periodically as it can be a expensive
>>> operation.
>>
>> Sure, under normal operation, as I understand it.
>>
>> IIUC, though, a nameserver restart is supposed to force the
>> write-to-journal immediately, right?
>
> No, I don't think so.

Doh, never mind. As has been pointed out elsewhere in this thread, it 
depends how named is stopped (rndc stop vs. halt, kill -XYZ and which 
signal).

If it's being stopped in an appropriate way to write the zone file, and 
it's not writing the zone file, then there really aren't many options - 
permissions, SELinux/AppArmour, or something similar.

If it's not being stopped in a way that'll write the zone file, change that.

Standard tricks like strace'ing the named process as you shutdown the 
daemon may help (strace -f -o -strace.txt p $NAMED_PID). I'm assuming 
there's nothing in the bind or system logs indicating an error.

TBH I'd drop the chroot - you're just complicating something that you're 
already having trouble with. Try it without a chroot and see if it 
behaves as you expect.


More information about the bind-users mailing list