This isn't, IMO, very useful as a response to the OP.
To sum up the response; "It's better to never fail!"
Yes, that seems pretty obvious. It *would* be better to never fail. Way, way
better.
But the big problem in life is; We're always failing! Dammit!
So, learning how to gracefully fail, and understanding what happens and why,
when something fails, is pretty important to achieve the outcome of; "Not
failing quite so catastrophically."
So, while I don't have helpful knowledge to impart to the OP, I think I can say
that giving the advice of "don't fail" doesn't seem very helpful.
RH> Am 16.12.20 um 17:37 schrieb Tim Daneliuk:
>> I ran into a situation yesterday which got me pondering something about bind.
>> In this case, a single line in a zone file was bad. The devops automation
>> had inserted a space in the hostname field of a PTR record.
>> What was interesting was that - at startup - bind absolutely refused
>> to load the zone file at all. I would have expected it to complain
>> about the bad record and ignore it, but load the rest of the
>> good records.
>> Can someone please explain the rationale or logic for this? Not complaining,
>> just trying to understand for future reference.
RH> it's better not load a invalid zone on a single nameserver at all as you
RH> are supposed to have at least two nameservers and the second one won't
RH> get the failure via master/slave replication
RH> if it has an error something is wrong
RH> if the last version had no error that version is good
RH> for the world *everything* still is good as long there is one slave -
RH> subtle errors can lead to completly unexpected behavior
RH> _______________________________________________
RH> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
_______________________________________________
Please 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
