Chroot Bind failed to start

[Reindl Harald]

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-bounces at lists.isc.org> On Behalf Of Reindl Harald
> Sent: Tuesday, March 15, 2022 10:01 AM
> To: bind-users at 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