Chroot Bind failed to start

[Reindl Harald]

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