botched KSK rollover

[/dev/rob0]

Oops.

I had it all figured out about 2 months ago and had generated new 
keys for ZSK (which I rolled over right away) and KSK.  The KSK 
change was slated for yesterday, but I forgot to get the DS to the 
parent zone before the inactivation of the previous KSK.

Sigh, it sure would be nice if I had a registrar with a means to 
automate DS submission.  But it's my fault for failing to set a 
reminder to do it manually.

I put a bandaid on the problem with dnssec-settime(8).  With that I 
reactivated the old dead key (this has me feeling a bit like 
Frankenstein! :) )  I added a week to inactivation,

# dnssec-settime -I+1w Knodns4.us.+005+60073.key

I thought I should then try deactivating the new one, but 
dnssec-settime did not like what I tried:

# dnssec-settime -i6d -S Knodns4.us.+005+60073.key Knodns4.us.+005+16408.key
dnssec-settime: fatal: Predecessor will become inactive before the
prepublication period ends.  Either change its inactivation 
date, or use the -i option to set a shorter prepublication 
interval.

I don't understand this error.  1w > 6d, right?

At this time I have 3 RRSIGs for DNSKEY: from both KSKs and the ZSK.  
According to both DNSViz and Verisign's dnssec-debugger this has put 
me back in business for the time being.  For some reason I am not 
successful in wrestling with Godaddy over the new DS, but that's not
a matter for this list.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
___
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: bind-chroot, runs, works, dies

[Petr Mensik]

Hi Reindl,

I have tested it and it has undesired side-effects. It would be great if pid 
files did not have to match systemd unit files. But presence of pid files also 
work as notification of completed initialization (which is done BEFORE forking 
and finishing ExecStart command).

Service type=simple is not good replacement of forking, because it does not let 
you know when service failed to start at all. If you already have something 
listening on your port and start named with
$ systemctl start named

It prints nothing, error code 0 - success. But you have to look at 
$ systemctl status named

to see there is actually failure. I would not expect that. It works better now.

Forking does allow you to first read basic configuration, initialize first. 
When that is successfully done, continue with daemonizing. Systemd will wait 
until it finds pid file created by daemonizing. Any initialization errors, even 
those that named-checkconf cannot find, are reported and you are told it did 
NOT start. Before "systemd start named" returns. I consider it important 
feature, worth still playing with pid files.

I think type=notify would be good replacement. It would requires support 
implemented in bind however, so it can tell you when it finished initialization 
and started handling requests. I think nothing such is implemented yet. At 
least I do not know about option for that.

While I agree pid files are strange relicts of old days, the way systemd 
handles them has some advantages over simple services. Unless bind supports 
sd_notify of systemd, I think default configuration has to stay playing with 
pid files. Of course if you want automatically restarted service, simple 
service may suit you. Not for default configuration however.

Regards,
Petr

--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973


- Original Message -
From: "Reindl Harald" 
To: bind-users@lists.isc.org
Sent: Friday, August 11, 2017 4:04:12 PM
Subject: Re: bind-chroot, runs, works, dies



Am 11.08.2017 um 15:57 schrieb Petr Mensik:
> Hi Todd.
> 
> I think much better than Ask Fedora would be filling a bug in 
> bugzilla.redhat.com. I would see it straight away.
> I am Fedora bind maintainer. If there is bug preventing correct start of 
> named-chroot, I would like to fix it.
> 
> You would see SElinux errors in command "ausearch -i -ts recent -m avc -m 
> user_avc -m selinux_err" if that errors were SElinux related.
> 
> I think your config file is missing pid-file "/run/named/named.pid"; It has 
> to match pid file used by your named-chroot.service. If systemd does not find 
> the pid file of forking service, it will cancel the service.
> PIDFile in named-chroot service includes chroot path, but configuration file 
> has to point to path inside chroot only.
> It should work with default configuration even when pid-file directive is 
> commented out. There is symlink from /var/run to /run also in 
> /var/named/chroot

and why in the world does the unit contain that pid-file stuff at all?

i maintain 25 production servers running on Fedora for nearly a decade 
and removed all that pid-file-stuff excatly becuse it causes only 
troubles long before most package maintainers provided systemd-units 
while as we deloyed F15 we overrided every single service with a unit in 
/etc/systemd/system

after 6 years running systemd nobody was able to show me a single 
service which needs a pid-file these days because the whole concept is 
broken by design when we have a system manager which can track services 
and processes proper

the pid-file stuff in systemd is last ressort for heavily broken software
___
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
___
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