On Mon, May 2, 2016, at 12:15 PM, Jeremy C. Reed wrote:
> What about using a specific zone file just for the purpose of the single
> A record you want to maintain using dynamic updates?
Well, this is a timely idea for another issue I've been working on ...
Could you expand on this a bit? Maybe
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 fi
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 err
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.
>
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?
>
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
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 resta
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 preserving my jnl files, but they're sill not getting written
to zone files on nameserver restart.
With this update file
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 comm
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 https://lis
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 k
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 a
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 *sho
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 recor
> 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 14
> 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}
/opt
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:
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 te
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 STRING"
show
send
nsupdate -k ./jason-key ./nsupdate.tx
On Tue, Apr 19, 2016, at 05:19 PM, Evan Hunt wrote:
> The "bad key type" message is a bug; it's been there for a while
...
> KEY is in fact what *should* be there, but the collision-
> checking function is expectingly DNSKEY, and so it complains.
Ok, so the data's good; just the detection whines f
On Tue, Apr 19, 2016, at 04:25 PM, Evan Hunt wrote:
> It's not "bad", dnssec-keygen can generate TSIG keys fine, it's just that
> it's cumbersome to remember all the options, and the keys are generated in
> a format that isn't directly useful.
Sure that's what I was doing anyway.
To be clean, I'm
On Tue, Apr 19, 2016, at 02:24 PM, Evan Hunt wrote:
> On Tue, Apr 19, 2016 at 07:40:38AM -0700, jaso...@mail-central.com wrote:
> > I'm working on generating TSIG keys for use with my bind server.
>
> I think you'll be happier if you use "tsig-keygen" instead of "dnssec-keygen".
Huh. Didn't co
I'm working on generating TSIG keys for use with my bind server.
When I generate a 2nd set of keys in a dir, I get a "bad key type" error,
DIR="/home/me/test/nsupdate"
HOST="myhost.example.com"
dnssec-keygen -V
dnssec-keygen 9.10.3-P4
cd $DIR
23 matches
Mail list logo
