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?
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
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
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
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
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
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
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
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
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
> 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
> 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}
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
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
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
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,
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
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
22 matches
Mail list logo
