Chroot Bind failed to start

[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 ☹.

Paul

-----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


-- 
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 at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users