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

On Mon, May 2, 2016, at 07:17 AM, Matthew Pounsett wrote: > The general procedure is > 1) use 'rndc freeze ' to stop dynamic updates to the zone > 2) edit the file > 3) use 'rndc thaw ' to re-enable dynamic updates > > If the zone is not set up to use dynamic updates, then: > 1) edit the zone

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

> > > > >On Mon, May 2, 2016, at 07:17 AM, Matthew Pounsett wrote: >> The general procedure is >> 1) use 'rndc freeze ' to stop dynamic updates to the zone >> 2) edit the file >> 3) use 'rndc thaw ' to re-enable dynamic updates >> >> If the zone is not set up to use dynamic updates, then: >> 1)

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

On 5/2/16, 10:17 AM, "Matthew Pounsett" wrote: > > > On 2 May 2016 at 10:05, wrote: >> General question -- >> >> When I want to change a zone file's data manually, say to add an A record, >> what's

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

On 2 May 2016 at 10:05, wrote: > General question -- > > When I want to change a zone file's data manually, say to add an A record, > what's the right procedure: > > If the zone is set up for dynamic updates, like the examples you've given, then in order to touch the

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

I'm pretty sure I got this sorted -- as you said, perms. With default ownership of root:named, both the zone & jnl files need to be group writeable inside the chroot. That's fixed now, and I'm getting jnl data written to zone files. (1) Thanks! (2) No idea why I see no logging of these perm

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

On Sun, May 1, 2016, at 11:34 AM, Phil Mayers wrote: > Days? That surely must be permissions? > > As per my other email - attach a strace to the bind process, and run > "rndc sync" / "rndc freeze" to force an immediate write-out - if there's > a permission problem the error should be apparent.

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

On 01/05/16 19:15, jaso...@mail-central.com wrote: On Sun, May 1, 2016, at 11:05 AM, Phil Mayers wrote: IIUC, though, a nameserver restart is supposed to force the write-to-journal immediately, right? No, I don't think so. Perhaps the behaviour in flush-zones-on-shutdown (which defaults to

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

On 01/05/16 19:05, Phil Mayers wrote: On 30/04/16 04:49, jaso...@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

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

On Sun, May 1, 2016, at 11:05 AM, Phil Mayers wrote: > > IIUC, though, a nameserver restart is supposed to force the > > write-to-journal immediately, right? > > No, I don't think so. > > Perhaps the behaviour in flush-zones-on-shutdown (which defaults to > "no") is what you're thinking of?

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

On 30/04/16 04:49, jaso...@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

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

Oops, s/write-to-journal /write-journal-to-masterfile / ___ 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

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

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

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

In message <1461987372.2397618.593994601.3d357...@webmail.messagingengine.com>, jaso...@mail-central.com writes: > On Mon, Apr 25, 2016, at 11:44 AM, jaso...@mail-central.com wrote: > > Now back to figuring this^ out :-/ > > I started from scratch, now on bind 9.10.4. > > After update, I'm

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

On Wed, Apr 27, 2016, at 06:30 AM, Matthew Pounsett wrote: > > Actually it is normal for privsep processes to chroot themselves, usually > > to /var/empty - e.g. > > Right, so "no chroot necessary" (which is what I was responding to) isn't > accurate. Oh. That's not what I got out of your

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

On 27 April 2016 at 03:07, Tony Finch wrote: > Matthew Pounsett wrote: > > > > Privsep doesn't actually fix the same problem chroot does. As I > > understand it, privsep reduces the attack surface for remote execution > > exploits by shuffling off privileged

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

Matthew Pounsett wrote: > > Privsep doesn't actually fix the same problem chroot does. As I > understand it, privsep reduces the attack surface for remote execution > exploits by shuffling off privileged operations to a separate process, but > if that process isn't chrooted

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

On Tue, Apr 26, 2016, at 11:18 AM, Matthew Pounsett wrote: > Both things together are better than either one alone. Thanks for the explanation. upstream bind-chroot with systemd should be easier and better documented ___ Please visit

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

On 25 April 2016 at 11:44, wrote: > > > > I completely gave up on chroot'd ntpd because of the endless weirdness. > Finally just moved to openntpd as (1) it had safe privsep, (2) no chroot > req'd, and (3) did the job I need. > Privsep doesn't actually fix the same

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

On Mon, Apr 25, 2016, at 11:33 AM, Matthew Pounsett wrote: > Unless you have a clear reason to do it (perhaps there's some security > consideration I haven't thought of) it seems to me it's unnecessary > complexity that would lead to problems just like this. Noted. Still, I'd honestly like to

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

On Monday, 25 April 2016, wrote: > > > On Mon, Apr 25, 2016, at 10:58 AM, Matthew Pounsett wrote: > > It's not clear to me why one would want to destroy/rebuild the chroot > every > > time you restart the process. > > Well, here > > (1) Because I inherited it this way,

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

On Mon, Apr 25, 2016, at 10:58 AM, Matthew Pounsett wrote: > It's not clear to me why one would want to destroy/rebuild the chroot every > time you restart the process. Well, here (1) Because I inherited it this way, and (2) The notes' quoted examples did that too, and (3) I'd not yet gotten

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

On 25 April 2016 at 13:53, wrote: > > > I suspect that there's something wrong with what is/isn't copied , and > maybe when, in that chroot build/destroy script. > It's not clear to me why one would want to destroy/rebuild the chroot every time you restart the process.

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

On Mon, Apr 25, 2016, at 10:46 AM, Matthew Pounsett wrote: > > Unfortunately, that^ returns no TXT record either. Which to me suggests > > the problem's 'earlier'. > > > > Yeah. I think you need to solve the problem with the vanishing journal > file first. But, the above dig is what you

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

On 25 April 2016 at 13:44, wrote: > > > On Mon, Apr 25, 2016, at 10:19 AM, Matthew Pounsett wrote: > > > TBH I don't understand WHAT to 'expect' from dig to test/verify this^. > > > What do I dig to get an answer with "TEST STRING" in it? > > > > dig in txt

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

On Mon, Apr 25, 2016, at 10:19 AM, Matthew Pounsett wrote: > > TBH I don't understand WHAT to 'expect' from dig to test/verify this^. > > What do I dig to get an answer with "TEST STRING" in it? > > dig in txt test.example.com @ns01.example.com Thanks. Unfortunately, that^ returns no TXT

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

On Sunday, 24 April 2016, wrote: > > This zone would not pass named-checkzone, which interestingly, is the > same code which named itself uses when initially loading a zone. > > It appears to > > named-checkzone -t /var/chroot/named example.com >

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

> This zone would not pass named-checkzone, which interestingly, is the same > code which named itself uses when initially loading a zone. It appears to named-checkzone -t /var/chroot/named example.com /namedb/master/example.com.zone zone example.com/IN: loaded serial

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

> What is deleting your journal? It's not named doing that. Hm. Maybe this destroy_chroot() { cp -af ${CHROOT}/namedb/master/*.signed /opt/etc/named/namedb/master/ should be destroy_chroot() { cp -af ${CHROOT}/namedb/master/*.{jnl,signed}

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

I'm in over my head a bit on these details, so appreciate the help. > The smoking gun is in the hand of systemctl ... Hadn't thought of that, but not surprised to hear it. I inherited this, and didn't yet monkey with systemd. But I can as needed. Here's the systemd unit file for named:

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

In message <20160424222541.gb22...@harrier.slackbuilds.org>, /dev/rob0 writes: > On Sun, Apr 24, 2016 at 12:04:15PM -0700, jaso...@mail-central.com wrote: > > I'm doing an nsupdate to a remote server from my desktop > > > > cat nsupdate.txt > > server ns01.example.com > > debug yes

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

On Sun, Apr 24, 2016 at 12:04:15PM -0700, jaso...@mail-central.com wrote: > I'm doing an nsupdate to a remote server from my desktop > > cat nsupdate.txt >server ns01.example.com >debug yes >zone example.net. >update add test.example.net. 500 in TXT "TEST

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

In message <1461526649.3652904.588164577.6d131...@webmail.messagingengine.com>, jaso...@mail-central.com writes: > > > On Sun, Apr 24, 2016, at 12:20 PM, Anand Buddhdev wrote: > > On 24/04/16 21:04, jaso...@mail-central.com wrote: > > > > Hey Jason, > > > > > checking with dig, it's NOT in

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

On Sun, Apr 24, 2016, at 12:20 PM, Anand Buddhdev wrote: > On 24/04/16 21:04, jaso...@mail-central.com wrote: > > Hey Jason, > > > checking with dig, it's NOT in 'TXT' where I expected it > > > > dig TXT example.net +short > > (empty) > > You added a TXT record for the name

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

On 24/04/16 21:04, jaso...@mail-central.com wrote: Hey Jason, > checking with dig, it's NOT in 'TXT' where I expected it > > dig TXT example.net +short > (empty) You added a TXT record for the name test.example.net, but you're looking for it at the name example.net. Of