How Zone Files Are Read

Gregory Sloop gregs at sloop.net
Wed Dec 16 17:26:00 UTC 2020


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20201216/e44e0210/attachment.htm>


More information about the bind-users mailing list