Am 15.03.22 um 15:14 schrieb Paul Amaral:
Reindi, thanks for the explanation, I do manually edit the zones because we
don’t make many DNS changes these days and I usually do named-checkzone but I
missed that this time, although I did reload that problematic zone with rndc
reload and saw no errors. I do have bind restarting once a week via chron. It
restarted early this morning and of course it failed to come up with no errors
in the log, making it difficult to troubleshoot ☹
than do yourself a favor and include the named-checkzone in your cron
script before restart it hard unattended in the middle of the night
(besides a weekly restart without any reason is questionable as you see
it's only asking for trouble)
-----Original Message-----
From: bind-users <bind-users-boun...@lists.isc.org> On Behalf Of Reindl Harald
Sent: Tuesday, March 15, 2022 10:01 AM
To: bind-users@lists.isc.org
Subject: Re: Chroot Bind failed to start
Am 15.03.22 um 14:37 schrieb Paul Amaral via bind-users:
Neverminded, I was able to traceback my steps and realize a fat
fingered a DNS entry in one of the zones, added two periods to an
authoritative zone’s DNS record, causing bind to fail to start. The
concerning issue was there was no error on the logs at all, making it
hard to figure out the issue.
that's the terrible packaging
Which leads me to the next question, let’s say I’m authoritative for
regular zone ABC.com and I fat fingered its DNS record,
ns1..something.com. Why would this affect the bind instance from
starting up?
because that's what ExecStartPre is for
if it fails the unit fails
Like I said there was nothing on the logs and I understand that might
be due to the Centos PKG itself. Just wondering why that mistake down
bind down and how I can get more meaningful logs on the logs even
those a prepackaged bind version.
the ExecStartPre happens long before named it even tried to start, so it can't
log anything - in my opinion the ExecStartPre stuff should go in it's own
script and just log but not fail the unit with a non-zero exit code
BTW: don't write directly in zone files and if you do so verify it at your own
- good chances named would refuse to start at it's own with such errors
that's why you *don't hard restart named* just because you changed a zone - a
reload most likely would have logged the error and just refused to reload the
zone itself
you need tools for altering zones which would refuse such wrong input before
they make it into the zone-file
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
